XML Protocol WG Candidate Recommendation Issues List

* S2.4, P1: Change "by the combination of [local name] and [namespace]"
to "by the XML qualified name"

The XMLP WG discussed this issue in a recent telcon and decided on the following 
course of action:

(i) Add a note to section 1.3 of part 1 as follows:

"This specification uses the term XML Expanded Name to refer to the 
value space pair {absolute URI reference,local-name} for a value of type 
xsd:Name. Similar terminology is under consideration for inclusion in future 
versions of [Namespaces in XML]. Should future versions of [Namespaces 
in XML] adopt alternative terminology, we anticipate that corresponding 
changes will be made to this recommendation in the form of an erratum, 
or in conjunction with some other future revision."

(ii) Where appropriate, replace the term 'XML qualified name' with 'XML 
expanded name' throughout part 1 and part 2.
  

James Sievert of Unisys has identified the following issue:
-----
I understand this up to the point at which I see an example like the
following in the SOAP Spec.:

GET /travelcompany.example.org/reservations?code=FT35ZBQ

I have to parse this.  If parsing wasn't meant to happen and URIs opaque,
why doesn't the Spec. use example URIs like the following:

GET /travelcompany.example.org/reservations/FT35ZBQ
-----

The XMLP WG discussed this issue during todays telcon and decided to close the 
issue with no action. It is entirely appropriate to GET a URI of the form 
"/travelcompany.example.org/reservations?code=FT35ZBQ" with the SOAP 
HTTP binding.
  

The fault examples in Part1 look like
    <env:Reason>Sender Timeout</env:Reason>
    (see example 4)

While the examples in Part0 look like
    <env:Reason>
       <env:Text xml:lang="en-US">Processing error</env:Text> 
       <env:text xml:lang="cs">Chyba zpracovn</env:Text> 
    </env:Reason>

The prose (and, as I read it, the schema) says that the text in Part 1
is wrong (all of them, not just the one quoted above).  Is it?

The XMLP WG discussed this issue during this weeks telcon and agreed 
that there was a problem. The examples will be corrected accordingly.
  

In table 15 [1] of Part 2 the value column for the "HTTP Method" field has:

According to the 
http://www.w3.org/2002/12/soap/features/web-
method/Method property (typically POST or GET).

The use of the word "typically" may be confusing to some readers, as it 
seems to imply that methods other than POST and GET are possibilities. 
However POST and GET are the _only_ methods allowed for this 
property.

The XMLP WG discussed this issue during a recent telcon and agrees that the 
wording in question could be confusing. The text will be modified as follows:

<original>
According to the 
http://www.w3.org/2002/12/soap/features/web-method/Method property 
(typically POST or GET).
</original>

<new>
According to the 
http://www.w3.org/2002/12/soap/features/web-method/Method property. 
POST and GET are the only values supported by this binding.
</new>
  

In Part 2 section 4.2.2 RPC Response [1] the first bullet states that:

"The response is represented by a single struct containing an outbound 
edge for the return value and each [out] or [in/out] parameter."

Nothing is specified about the name of the struct. Should another 
sentence be added to the first bullet such as:

"The name of the struct is not significant."

to prevent confusion?

The XMLP WG discussed this issue during a recent telcon and agrees with your 
proposed clarification. Your suggested text will be incorporated into 
the specification.
  

There is an inconsistency between section 2.7.4 (SOAP Intermediaries 
and Relayed Infoset) in part 1[1] and the descriptions of the SOAP 
mustUnderstand, role and relay attributes.

Section 2.7.4 states that "All XML infoset properties of a message MUST 
be preserved with the following exceptions: [long list]" but doesn't 
mention anything about the mustUnderstand, role and relay attributes.

However, in contradiction to this:

(i) Section 5.2.2 [2] (SOAP role Attribute) states that 'If relaying the 
message, a SOAP intermediary MAY omit a SOAP role  attribute 
information item if its value is 
"http://www.w3.org/2002/12/soap-envelope/role/ultimateReceiver"'.

(ii) Section 5.2.3 [3] (SOAP mustUnderstand Attribute) states that 'If 
relaying the message, a SOAP intermediary MAY substitute "true" for the 
value "1", or "false" for "0". In addition, a SOAP intermediary MAY 
omit a SOAP mustUnderstand  attribute information item if its value is 
"false"'.

(iii) Section 5.2.4 [4] (SOAP relay Attribute) states that 'If relaying 
the message, a SOAP intermediary MAY substitute "true" for the value 
"1", or "false" for "0". In addition, a SOAP intermediary MAY omit a 
SOAP relay attribute information item if its value is "false"'.

I think this was an oversight when section 2.7.4 was constructed and to 
restore consistency I propose that we add three bullets to the list in 
section 2.7.4 as follows:

19 SOAP role attribute information items that are present in the 
[attributes] property of SOAP Header block element information items 
may be transformed as described in 5.2.2 SOAP role Attribute.

20 SOAP mustUnderstand attribute information items that are present in 
the [attributes] property of SOAP Header block element information 
items may be transformed as described in 5.2.3 SOAP mustUnderstand 
Attribute.

21 SOAP relay attribute information items that are present in the 
[attributes] property of SOAP Header block element information items 
may be transformed as described in 5.2.4 SOAP relay Attribute.

Issue 401 was discussed on todays XMLP telcon and the fix suggested by 
the issue originator was adopted as the issue resolution.
    

I was given an action item by the group developing the SQL/XML
specification to inform the XML Protocol Working Group of a change being
made to the SQL/XML document.

We are aware that the XML Protocol WG, of which you are the chair, is using
SQL/XML's "escape sequence" algorithm in your specifications.  We also
believe that your use of that algorithm is by copy and not by reference, so
we think that it is incumbent on us to notify you if we change our
algorithm so that you can consider whether or not to change yours
correspondingly.  Please circulate this to your Working Group as you feel
appropriate.

The change that we have made is fairly simple, in fact.  As you will
recall, we represent Unicode characters from the Basic Multilingual Plane
(BMP) either as their native character or as an escape sequence of the form

"_xXXXX_", where "XXXX" represents exactly four hexadecimal digits
(hexits).  Unicode characters not on the BMP were formerly represented by
an escape sequence of the form "_xXXXXXXXX_", using exactly eight hexits.

In order to better align with the Unicode Consortium's requirements and
recommendations, we have agreed to change the non-BMP escape sequence to
use exactly *six* hexits instead of eight: _xXXXXXX_

If you would like more information about this change, you might be
interested to read the paper that proposes this change.  You can find it
at:

ftp://sqlstandards.org/SC32/WG3/Meetings/ZSH_2003_01_SantaFe_USA/zsh044R1-Unicode-Character-Hexits.pdf

The XMLP WG today decided to change the description of the "escape
sequence algorithm" in the SOAP 1.2 specification to match the change you
describe. 
    

There is an editorial issue related to section 5.4.7.3.
It is a cut-and-paste error from section 5.4.8.2.

Section 5.4.7.3 defines SOAP qname AII as it can appear on the
SupportedEnvelope EII. Section 5.4.8.2 defines SOAP qname AII as it can
appear on the NotUnderstood EII. But the text in both the sections is
identical.

The following text in section 5.4.7.3:

"Its value is the XML qualified name of a SOAP header block which the
faulting node failed to understand.
      Note: When serializing the qname attribute information item there needs
    to be an in-scope namespace declaration for the namespace name of the SOAP
    header block that was not understood and the value of the attribute 
    information item uses the prefix of such a namespace declaration. The 
    prefix used need not be the same as the one used in the SOAP message that 
    was not understood. "

should be changed to something along the lines of:

  "Its value is the XML qualified name of the SOAP Envelope EII that is
  supported by the faulting node.
      Note: When serializing the qname attribute information item there needs 
    to be an in-scope namespace declaration for the namespace name of the SOAP 
    Envelope EII that is supported by the faulting node and the value of the 
    attribute information item uses the prefix of such a namespace declaration.  " 

or something like this.

The issue was closed with instructions to the editors to fix 
the problem along the lines you suggest. The new wording for the 
offending text in 5.4.7.3 is:

"The type of the qname attribute information item is xs:QName. Its 
value is the XML qualified name of a SOAP Envelope element information 
item that the faulting node can understand.

Note:
When serializing the qname attribute information item there needs to be 
an in-scope namespace declaration for the namespace name of the SOAP 
Envelope element information item that the faulting node can 
understand. The value of the attribute information item uses the prefix 
of such a namespace declaration."
    

The CR version of Part 2 points to the Schema file at
http://www.w3.org/2002/12/soap-encoding. According to the comments embedded
in that Schema, the simple types of the SOAP Encoding are:

duration
dateTime
time
date
gYearMonth
gYear
gMonthDay
gDay
gMonth
boolean
base64Binary
hexBinary
float
double
anyURI
QName
string
normalizedString
token
language
Name
NMTOKEN
NCName

I am surprised _not_ to see types such as Integer in this list, although
Integer (and others) are listed later under a comment that says "For
compatibility with XML 1.0 the following element declaration and associated
complex type definition should NOT be used. It is provided here for
completeness".

(i) The current SOAP encoding schema is correct but the comments half 
way through could be misleading.
(ii) The schema document will be re-arranged to group the commented 
element declarations at the end of the document and the comments will 
be reworded for clarity.
    

Decide whether SOAP 1.2 is one or three specs. If a "Part" could
ever conceivably be updated without the others, I'd say it's three.
XML Schema was treated as one spec though it has three parts. Then
SOAP 1.2 "specification(s)" should match throughout the primer.

Decide whether to capitalize primer (Primer) or not and use that
throughout.

This page shows how to link to Parts 1 and 2 from within Part 0.
People reading from printouts need to know part and section numbers.

http://www.w3.org/2001/06/manual/#linking-within

Words in the TOC and headings can be capitalized, for example, 2.2.2
Remote Procedure Calls and 4. Using Various Protocol Bindings.

Reword to avoid "we" (even if that means using the passive voice). For
example, s/In section 2.2.1 we return to our example/Section 2.2.1
returns to the example/

http://www.w3.org/2001/06/manual/#Translations
http://lists.w3.org/Archives/Public/www-international/2000AprJun/0058

There are 151 occurrences of style="color: #000000" that need to be
cut.

In several places, style="color: #000000" turns links from blue to
black, for example:
     <a href="#L10309" style="color: #000000">section 4.1</a>

There are 13 empty <span>s and one empty <code> that can be cut.

The tables need summary attributes.

W3C uses en-US. You could replace the whilsts (chiefly British) with
whiles.
     http://www.m-w.com/cgi-bin/dictionary?va=whilst

Also you could, in the first occurrence, do something like "primer
(pronounced <em>prim</em>-er)" as an aid to the reader. prime-er is
chiefly British.

     http://www.m-w.com/cgi-bin/dictionary?va=primer
     http://www.bartleby.com/61/wavs/87/P0558700.wav

"The document is believed to be stable, and to encourage implementation
by the developer community." needs re-writing to be a complete sentence.

Some of the following need global replacement, some are single occurrences.

s/simplicitly/simplicity/
s/behaviour/behavior/
s/Recommandation/Recommendation/
s/accomodate/accommodate/
s/[XML InfoSet]/[XML Infoset]/
s/realise/realize/
s/W3C members/W3C Members/
s/the following criterion/the following criteria/
s/Implementation experience have been gathered/Implementation experience has been gathered/
s/W3C membership/W3C Membership/ 
s/progress."A/progress." A/ 
s/corresponding XML Infosets/corresponding XML infosets/ (I think, not sure)
s/SOAP Part 2 Tabe 16/SOAP Part 2 Table 16/
s/NOT recommended/<strong>not</strong> recommended/
s/Web Architecture/Web architecture/
s/et al/et al./
s/Usage Scenarios WD/SOAP Version 1.2 Usage Scenarios Working Draft/
s/Members of the Working Group/Participants in the Working Group/
s/Tibco/TIBCO/
s/Mitre/MITRE/
s/Previous members/Previous participants/
s/(EDF (Electricite de France))/(EDF [Electricit&eacute; de France])/
s/Hewlett Packard/Hewlett-Packard/
s/Developmentor/DevelopMentor/

I saw about 6 links that contain their preceding space. For example,
this needs a space after "called":
          called<a href="http://www.w3.org/TR/2002/CR-soap12-part1-20021219/#encapsulation"> 
	  header blocks</a>
   (same for "which is a role", "the ultimate SOAP receiver", "variety of
		    message exchange patterns", "sub-element, env:Node")

The second occurrence of Interface Definition Language should be
capitalized. Either that or establish (IDL) after the first occurrence
and use that in the second.

In "freestanding [XML 1.0]" the reference link is missing.

This sentence is too long:

      Furthermore, in the case when an RPC definition is such that all
      parts of its method description can be described as
      resource-identifying and hence the entire resource may be
      identified by a URI, and the supplier of the resource can assure
      that a retrieval request is safe, then SOAP Version 1.2 recommends
      that the choice of the Web method property of GET and the use of
      the SOAP Response message exchange pattern used as described in
      section 4.1.1.

It could be two, something like:

      When all parts of an RPC definition method description can be
      described as resource-identifying, the entire resource may be
      identified by a URI. In this case, if the supplier of the resource
      can assure that a retrieval request is safe, then SOAP Version 1.2
      recommends the Web method property of GET and the SOAP Response
      message exchange pattern used as described in section 4.1.1.

This paragraph confused me:

      SOAP Version 1.2 has a number of changes in syntax and provides
      additional (or clarified) semantics from those described in [SOAP
      1.1]. The following is a list of features where the two
      specifications differ. The purpose of this list is to provide the
      reader with a quick and easily accessible summary of the
      differences between the two specifications. The following list has
      been put in categories purely for ease of reference, and in some
      cases, an item might equally well have been placed in one or
      another category.

It could be shorter, something like:

      SOAP Version 1.2 has a number of changes in syntax and provides
      additional and clarified semantics from those in [SOAP 1.1]. The
      following is a summary of features where the two specifications
      differ. The categories are purely for ease of reference. In some
      cases, an item might equally well have been placed in another
      category.

Reference titles should point to the dated version. See: 
    http://www.w3.org/2001/06/manual/#References 
    "If there is an institutionalized identifier (URI) for a document, 
    cite the most specific identifier. For example, link to 
    http://www.w3.org/TR/1999/REC-html401-19991224 rather than to 
    http://www.w3.org/TR/html4/."

In References and throughout, you have "[SOAP Part1]" yet "[XML Schema 
Part 1]". I would make the spacing match. Same for part 2.  
Also in References, for [SMTP] you can link to those RFCs and treat 
them like the other references. I think IETF recommends URIs like this: 

    http://www.rfc-editor.org/rfc/rfcNNNN.txt
  

As editor, I was assigned to handle your editorial comments, which was assigned
as CR Issue #405. I have handled the vast majority of them fully, and show the
detailed disposition of comments below. This issue is now closed, and further 
editing, if felt necessary, will be done at a future date.
  

The files would be 10% smaller if run through HTML Tidy with indent off.
http://tidy.sourceforge.net/

Please remove this CSS rule to fix display in Mac IE and Opera:

     dt.label       { display: run-in; }

It looks like this HTML was generated with an old version of the
xmlspec XSLT stylesheet. To see one reason why, see the Mac IE screen
shot at http://www.w3.org/2003/01/26-soap1.png. This rule also makes
references markup fragile (doesn't apply to what you have right now).

Does this rule come from the xmlspec XSLT?

      li, p           { margin-top: 0.3em;
                       margin-bottom: 0.3em; }

I would omit it because optimal vertical spacing is font-dependent and
W3C CSS says only that TRs are "sans-serif" with unknown metrics. If it
did come from that stylesheet please let me know so it can be reported.

The tables need summary attributes to meet WCAG 1.0 Level A (required).
http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505/#gl-table-markup

From Status of This Document:

 s/Recommandation/Recommendation/
 s/W3C members/W3C Members/
 s/W3C membership/W3C Membership/
 s/progress."A/progress." A/
 s[XML InfoSet]/[XML Infoset]/

References should be written like these (I should note this section may
change): http://www.w3.org/2001/06/manual/#References

From Acknowledgments:

s/Members of the Working Group/Participants in the Working Group/
(see http://www.w3.org/Consortium/Process-20010719/groups.html)
 s/Tibco/TIBCO/
 s/Mitre/MITRE/
 s/Previous members/Previous participants/
 s/(EDF (Electricite de France))/(EDF [Electricité de France])/
 s/Hewlett Packard/Hewlett-Packard/
 s/Developmentor/DevelopMentor/
  

The editors have incorporated the vast majority of your suggestions 

In "XML schema," schema can be lowercase except when referring to the
XML Schema Recommendation.

In 1.5.1, s/SOAP Module/SOAP module/

The third sentence is too long:

     This section sets out the rules by which SOAP messages are
     processed. Unless otherwise stated, processing MUST be semantically
     equivalent to performing the following steps separately, and in the
     order given. Note however that nothing in this specification
     prevents the use of optimistic concurrency, roll back, or other
     techniques that might provide increased flexibility in processing
     order provided all generated SOAP messages, SOAP faults and
     application-level side effects are equivalent to those that would
     be obtained by direct implementation of the following rules in the
     order shown below.

The para. could be something like (I may have this wrong):

    This section sets out the rules by which SOAP messages are
    processed. Nothing in this specification prevents the use of
    optimistic concurrency, roll back, or other techniques that might
    provide increased flexibility in processing order. Unless otherwise
    stated, processing of all generated SOAP messages, SOAP faults and
    application-level side effects MUST be semantically equivalent to
    performing the following steps separately, and in the order given.

Generally, white space is two words. Does "Whitespace character
information items" make more sense as "White space character information
items"? I believe so (see http://www.w3.org/TR/REC-xml#sec-common-syn).

  s/message exchange patterns/Message Exchange Pattern/ (or the reverse)
  s/does NOT require/does <strong>not</strong> require/
  s/whitespace characters/white space characters/
  

The editors have incorporated the vast majority of your suggestions 

In the Abstract, s/Part1/Part 1/

Words in the TOC and headings can be capitalized evenly. For example,
3.1.2 Encoding Simple Values, and C.1 Validating Using the Minimum
Schema.

Depending on timing this can be XML 1.1 as I imagine is well known.
You could have XML 1.1 as a reference marked "work in progress."
     Note that certain Unicode characters cannot be represented in XML 
     (see [XML 1.0]).

Somewhere in 3 and 4, "Remote Procedure Calls (RPC)" should appear.
(Right now the full name and initialism are separated.)

This sentence is too long:
 Conventions for specific URI encodings of procedure names and 
 arguments, as well as for controlling the inclusion of such 
 arguments in the SOAP RPC body could be established in conjunction 
 with the development of Web Service interface description
 languages, could be developed when SOAP is bound to particular
 programming languages, or could be established on an application or
 procedure-specific basis.

It could be something like:

    Conventions for specific URI encodings of procedure names and
    arguments, as well as for controlling the inclusion of such
    arguments in the SOAP RPC body could be established in conjunction
    with the development of Web Service interface description
    languages. They could be developed when SOAP is bound to particular
    programming languages. They could be established on an application
    or procedure-specific basis.

s/does NOT support/does <strong>not</strong> support/
s/meta-data/metadata/ (I think)
s/XML Schema type/XML schema type/
s/whilst/while/
s/HTTP Status Codes/HTTP status codes/
s/STRONGLY RECOMMENDED/<strong>strongly</strong> RECOMMENDED/
s/Unicode Scalar Values/Unicode scalar values/

"See http://www.w3.org/TR/charmod/#sec-Transcoding" should be a
reference something like [CHARMOD] with a note that it is "work in
progress." The Unicode Standard Annex #15 "Unicode Normalization Forms"
(http://www.unicode.org/unicode/reports/tr15/) could also be a
reference. The rules for citing Unicode are near the bottom here:
http://www.unicode.org/unicode/standard/versions/

In the first occurrence say "Normalization Form C (NFC)" if you are
going to abbreviate it.
  

The editors have incorporated the vast majority of your suggestions 

One thought for your "SOAP Version 1.2 Part 2: Adjuncts" Candidate
Recommendation [1]. Why so many appendixes? Because they are normative
and so interesting, I think they could be part of the main spec.
I don't see immediately a need to make them appendixes to adjuncts.
  

the XMLP WG has decided to close the CR Issue 409 by
keeping the status quo. Our rationale follows.

Looking at the list of Part 2 Appendices [2]:

Appendix D - Acknowledgements - is obviously an appendix.

Appendix A is not only relevant for the HTTP binding, but it is not an
adjunct to SOAP 1.2 as such, it's more like a note to the HTTP binding
and other interested parties (like the IETF).

The other two appendices (B and C) are also just notes relevant to their
respective sections; they don't naturally fit in the sections but they
don't seem to deserve section status themselves.

Altogether, we believe the appendices have the right status.
  

It occurs to me that by moving some of the best examples to Part 1 or
Part 2 that Part 0 could possibly be eliminated giving people 150k less
to read. The SOAP specification is very clean and easy to read, so I
wonder if three parts are necessary.
  

The XMLP WG discussed your comment made against the SOAP v1.2
specifications at a recent teleconference and came to the conclusion
that it was necessary to retain the SOAP specification in 3 parts.
Therefore, the primer will not be eliminated and its examples not moved
to Parts 1 and 2.
  

This question came up during an implementer's interop test session: Is an
intermediary obliged to preserve namespace prefixes? The spec says nothing
explicitly (that we could find) but appears to implicitly oblige
intermediaries to preserve them. What did the WG intend?
  

The XMLP WG decided to amend bullet 18 of the text in
Part 1 of the CR WD to read as follows:

All namespace information items in the [in-scope namespaces] of element
information items MUST be preserved. Additional namespace information
items MAY be added.

You can see this text as bullet 21 at[3] ( bullet 22 is the old text ).
Note that several other modification have been made to this section as a
result of CR feedback hence the renumbering of the bullets.
  

  The CR and Ed Copy versions of the SOAP-Encoding schema
  (http://www.w3.org/2002/12/soap-encoding) do not appear to contain an
  attribute declaration for valueType (see
  http://www.w3.org/TR/2002/CR-soap12-part2-20021219/#valueTypeattr). We (the
  SOAP implementer's group) suspect this is a simple omission, yes?
  

It was missing an attribute declaration for the valueType
attribute. The schema has been updated appropriately in the editor's
copy.
  

I found an error in the section 6 of SOAP 1.2 Primer CR document.
In the following sentences, "env:faultReason" should be "env:Reason".

* SOAP 1.2 uses the element names env:Code and env:faultReason, respectively,
for what used to be called faultcode and faultstring in SOAP 1.1. SOAP 1.2 also
allows multiple env:Text child elements of env:faultReason qualified by 
xml:lang to allow multiple language versions of the fault reason.
  

The text has been corrected in the latest editor's copy of the Primer [1].
This closes CR Issue 413.
  

I found in section 6 of the primer another reference to what I thought to be
an error:
<< 
SOAP 1.2 has added an optional attribute enc:nodeType to elements encoded 
using SOAP encoding that identifies its structure (i.e., a simple value, 
a struct or an array). 
>>

In fact, the resolution of issue 231 was to add "nodeType" and not
"valueType". Part2 (and the soap encoding schema) defines valueType whereas 
Part0 mentions nodeType.
Actually, the vote had decided to use nodeType, see http://www.w3.org/2000/xp/Group/2/10/02-minutes.html.
  

The XMLP WG realised it made a mistake recently in 'resurrecting' valueType
when it had previously decided to use the attribute called nodeType. The
documents and schema are being changed (back) to  describe nodeType.
  

The copyright statements in the schema for encoding
(http://www.w3.org/2002/12/soap-encoding) and rpc
(http://www.w3.org/2002/12/soap-rpc) etc still list INRIA. Given the
copyright changes to the main spec docs, surely the schema should be
similarly treated?

At the point those schemas were published, INRIA was still the copyright holder,
I think... The schemas in the editors directory have been updated to the new 
copyright, so next time we publish the schemas, we should be all set.
  

  I am wondering if there is a new URL for Envelope Schema of SOAP 1.2. When I
  check <http://www.w3.org/2001/12/soap-envelope> , the "relay" attribute is
  not defined in the schema. Sorry if this has been brought up before. Thanks!

  You identified an issue with the soap envelope schema regarding a
  missing relay attribute declaration. This error has been corrected in
  the editor's copy. Thank-you for bringing this to the attention of
  the working group.
  

It seems that the language in part 2 sections 4.2.1 and 4.2.2 [1] may be
uclear to folks coming from SOAP 1.1 about the intent that when using
SOAP RPC the SOAP:Body element only contains a single child element with
the invocation or response. 

The comment came to me last week from one of our developers.

  Issue withdrawn by originator (see minutes of 12 march 2003 teleconference)
  

Currently the "action" parameter in the SOAP 1.2 media type is only described 
in appendix A of part 2, and not mentioned in the HTTP binding or anywhere 
else in the document.  As this parameter is (optionally) supported, and may be 
important for some implementations, it is important to have a consistent way 
to describe how to set it.

During this week's WS-Desc telcon, we discussed a proposal to express the value
of the action parameter in WSDL as a Property (per the SOAP 1.2/WSDL 1.2 
feature/property extensibility model), in a very similar manner to Web-Method.  However, we noted that the HTTP binding should really expose this feature 
explicitly, again, for exactly the same reasons we exposed web-method as a 
property.  We therefore propose the following change to the SOAP 1.2 spec:

PROPOSAL:  Introduce an "action" feature with a single defined property 
("http://www.w3.org/2002/12/soap/features/action/Action") which has the 
behavior of setting the MIME action parameter in bindings.  The HTTP binding 
would natively support this feature.

This is a fairly minor change to the spec, which would not change 
implementations in any way.  However, it would make description languages 
(WSDL) and other specifications easier to write, in line with the reasons 
for the feature/property model in the first place.

Note that it is certainly possible to write implementations which set this 
parameter using custom APIs, and other specs (including WSDL) which refer to 
it in english, but this seems to be just the sort of thing which should be 
expressed with the model.

Alternately, the same feature could be described and "overlaid" on top of the 
HTTP binding in a separate note, but that would, to some extent, break the 
clean encapsulation of bindings-as-feature-implementors.  In other words, 
publishing a separate spec/note which says "oh, by the way the normative HTTP 
binding also supports this new feature here" is no guarantee that all 
implementations of the binding will recognize/refer to the correct property 
values if they are referenced in WSDL descriptions or other specifications.

The XML Protocol WG has
resolve this issue, and the editors have added a SOAP Action feature to
Part 2 [2] along the lines of the proposal at [3].
  

I looked back at my notes and found the reason for my misplaced belief that
the empty role URI mapped to the ultimate receiver... it's Tests T9 through
T14 in the SOAP 1.2 Test Collection:

http://www.w3.org/2000/xp/Group/3/02/28-ts/soap12-testcollection.html

which test this case and make the same (false) assumption. I had
implemented these for testing purposes [1] and will for now consider them suspect.
    

You identified an issue with the tests T9 through T14 of the
SOAP Version 1.2 Test Collection document. Following resolution of issue
233 of the Last Call issue list [2], those tests will be updated per SOAP
Version 1.2 CR [3]

I was just rechecking the editors' copy of part 1.   As best I can tell,
the relay rules allow comments to be inserted and deleted, but the chapter
5 definition of the envelope doesn't allow them to be there in the first
place.  Am I just missing it in chapter 5, or is there a bug in the draft?
    

The workgroup has agreed to resolve the issue as follows:

* We note that our resolution to last call issue [2] #355 the workgroup
agreed that "comments are allowed anywhere in the [document element] but
not before or after that element."  It also clarified the rules for
relaying comments through an intermediary.

* We have concluded that the decision on 355 was incompletely implemented,
and in particular that Chapter 5 of part 1 is to be updated to reflect this
decision.  We specifically have agreed to adapt the text quoted above,
suitably modified to reflect Infoset terminology, etc.

* We considered and rejected proposals to make optional transmission of
comments by bindings.  Accordingly, bindings MUST transmit comments if they
appear in the message Infoset.  This was the status quo, insofar as
bindings are already required to transmit the entire Infoset.  We rejected
a proposal to add a "note" clarifying the requirement to transmit comments.
  

Hi, part 1 lists the enc: namespace prefix among the "Prefixes and
Namespaces used in this specification" while the prefix is not used
anywhere in part 1. 

I suggest that it is delisted as an editorial change.
    

the CR issue #422 has been closed by the XMLP WG by accepting the
proposed changes.
  

  <org/TR/2004/CR-xop10-20040826/>>, [MTOM] and [SOAP
Representation Header] refer to their documents as Working Drafts but
point at the URI of the CR. Appendix B would benefit from following some
of the guidelines for references sections, see

  http://www.w3.org/2001/06/manual/#ref-section

You can use

  http://www.w3.org/2002/01/tr-automation/tr-biblio-ui

to generate the relevant markup. Following this format will also help
you to update outdated references, for example the [XML InfoSet]
reference points at the First Edition of the document while the latest
version is the Second Edition, see

  http://www.w3.org/2004/07/references-checker-ui

Bjoern,
You raised an issue, 500 [1] regarding the reference section of XOP.
The reference section of XOP, MTOM and RRSHB are now following W3C's 
manual of style [2].
Please check the latest editors copies [3][4][5] and please tell the group 
if this satisfies your concerns.

1. What happens when the resource in the rep:Data element has an
xmlmime:contentType attribute for a textual type, such as text/* or
application/*+xml?  The charset handling should be discussed
here (unless text/*, application/*+xml and other text types are
explicitly forbidden).

2. If text types are allowed, what does it mean to have and not have a
charset attribute?

3. If text types are allowed, is base64 still a requirement?  What
happens when you have the SOAP document in one charset and the SOAP RRH
with a text document in another charset?  While we understand that
requiring the base64 type simplifies processing and avoids unnecessary
character encoding processing, it does introduce some additional
opportunity for encoding mismatches to occur.

4. What heppens when the resource in question is available in multiple
languages?  If the language negotiation is done by the resource host,
how is that indicated to the receiving service?  There should be the
possibility of xml:lang on the resource.

  

   We received your note [1] which raises a number of questions about our
issue 501 [2].  This note deals primarily with your concern that:

"We also believe that forcing base64 encoding on readable text is a mistake
which will introduce a number of problems, not the least of which is
masking the fact that the inline data needs to be tagged.  We feel it
should be strongly discouraged, if not disallowed."

We think that perhaps the design point of XOP and MTOM may have been
misunderstood.  The intended purpose of XOP and MTOM is to allow binary
octet streams to be carried in XML documents in a manner that allows for
good optimization of storage and networking formats.  Stated differently,
the purpose of XOP and MTOM is to provide for tunnelling of binary data in
an optimized way.    Like most filesystems and other systems that manage
octet streams, we specifically avoid "spying on" the contents of that data
or providing for special behavior according to the contents.  We don't
provide special facilities for the case where the stream happens to be
"image/jpeg" and we don't for "text/*" either.  While it's true that any
system that supports octet streams can be used in the special case where
the content happens to be encoded text, that is not the focus of XOP or
MTOM, and we are reluctant to provide special mechanisms for dealing with
text.   Indeed, where such special handling is desired, XOP and MTOM should
not be used.  We think that users can make that decision according to their
needs.  When XOP and MTOM are used, they should be viewed as a completely
opaque tunnel;  the data should be treated as characters only before it is
encoded or after it has been "extracted" from its encapsulated form.

You ask:  "why base64Binary" for text input streams?  As discussed above,
we strongly believe that we should not treat text differently from other
octet streams.  To reiterate why we use base64Binary for all such streams:
XOP and MTOM do their jobs by establishing a correspondence between binary
data stored in its "native" form as a "part" in MIME, and a corresponing
character representation in an Infoset.  For this, base64Binary is provides
a natural and standardized character representation.  It is a byproduct of
this design that if a user choosesto tunnel character data as if it were
binary, the representation will indeed seem somewhat more appropriate to
binary content than to text.  In situations where this is not the desired
behavior,  XOP and MTOM should not be used.

We note as an aside that if someone did decide to use MTOM with, say, an
XHTML document encoded in BIG5, and if you looked at the corresponding XOP
MIME part, you would find exactly the BIG5 stream not the base64Binary
characters;  the base64Binary characters are an artifact defined by the
specification, to be used only in the case where the application
specifically needs a view of the data in the Infoset.  For example, one
might compute a digital signature for the entire containing infoset,
including the base64 characters corresponding to the nested document.  It
is anticipated that realistic implementations will not in fact surface the
base64 character form on the wire, in memory, or through APIs unless
requested for some such purpose.  So, there is emphasis in practice on
dealing directly with the BIG5, in this example, as opposed to the
base64Binary encoding of the BIG5.

A related issue about which you ask is the means by which metadata about
the nested or tunneled octet stream can be conveyed.  This is
architecturally orthogonal to XOP and MTOM in our design.  For example, we
recommend the use of the xmime:content-type attribute [3] with
base64-encoded octet streams in any case where they correspond to
MIME-typed documents, and regardless of whether such content is to be
optimized with XOP or conveyed in a normal XML 1.0 or XML 1.1 character
stream.  Conversely, other forms of description could be used without
changing MTOM or XOP.   We have taken the trouble to define the one
attribute, xmime:content-type that we feel will be of particularly general
utility;  we invite you and other members of the XML community to define
additional such attributes that may be necessary for purposes such as i18n.
We also note that the working draft at [3] says of the xmime:content-type
attribute:

"The [normalized value] of the contentType attribute information item MUST
be the name of a IANA media type token, e.g., "image/png", "text/xml;
charset=utf-16""

which specifically illustrates the use of charset.   We generally decline
to provide normative information in two places;  in this case, we think
that it's appropriate that use of the charset specification is indeed
documented with the normative recommendation for the xmime:content-type
attribute and not in xop or mtom themselves.  

We hope that this note clarifies the reasons for the decisions we have
made.

[Point 1 clarification]
   We received your note [1] which raises a number of questions about our
issue 501 [2].  This note deals primarily with your concern that:

"We also believe that forcing base64 encoding on readable text is a mistake
which will introduce a number of problems, not the least of which is
masking the fact that the inline data needs to be tagged.  We feel it
should be strongly discouraged, if not disallowed."

We think that perhaps the design point of XOP and MTOM may have been
misunderstood.  The intended purpose of XOP and MTOM is to allow binary
octet streams to be carried in XML documents in a manner that allows for
good optimization of storage and networking formats.  Stated differently,
the purpose of XOP and MTOM is to provide for tunnelling of binary data in
an optimized way.    Like most filesystems and other systems that manage
octet streams, we specifically avoid "spying on" the contents of that data
or providing for special behavior according to the contents.  We don't
provide special facilities for the case where the stream happens to be
"image/jpeg" and we don't for "text/*" either.  While it's true that any
system that supports octet streams can be used in the special case where
the content happens to be encoded text, that is not the focus of XOP or
MTOM, and we are reluctant to provide special mechanisms for dealing with
text.   Indeed, where such special handling is desired, XOP and MTOM should
not be used.  We think that users can make that decision according to their
needs.  When XOP and MTOM are used, they should be viewed as a completely
opaque tunnel;  the data should be treated as characters only before it is
encoded or after it has been "extracted" from its encapsulated form.

You ask:  "why base64Binary" for text input streams?  As discussed above,
we strongly believe that we should not treat text differently from other
octet streams.  To reiterate why we use base64Binary for all such streams:
XOP and MTOM do their jobs by establishing a correspondence between binary
data stored in its "native" form as a "part" in MIME, and a corresponing
character representation in an Infoset.  For this, base64Binary is provides
a natural and standardized character representation.  It is a byproduct of
this design that if a user choosesto tunnel character data as if it were
binary, the representation will indeed seem somewhat more appropriate to
binary content than to text.  In situations where this is not the desired
behavior,  XOP and MTOM should not be used.

We note as an aside that if someone did decide to use MTOM with, say, an
XHTML document encoded in BIG5, and if you looked at the corresponding XOP
MIME part, you would find exactly the BIG5 stream not the base64Binary
characters;  the base64Binary characters are an artifact defined by the
specification, to be used only in the case where the application
specifically needs a view of the data in the Infoset.  For example, one
might compute a digital signature for the entire containing infoset,
including the base64 characters corresponding to the nested document.  It
is anticipated that realistic implementations will not in fact surface the
base64 character form on the wire, in memory, or through APIs unless
requested for some such purpose.  So, there is emphasis in practice on
dealing directly with the BIG5, in this example, as opposed to the
base64Binary encoding of the BIG5.

A related issue about which you ask is the means by which metadata about
the nested or tunneled octet stream can be conveyed.  This is
architecturally orthogonal to XOP and MTOM in our design.  For example, we
recommend the use of the xmime:content-type attribute [3] with
base64-encoded octet streams in any case where they correspond to
MIME-typed documents, and regardless of whether such content is to be
optimized with XOP or conveyed in a normal XML 1.0 or XML 1.1 character
stream.  Conversely, other forms of description could be used without
changing MTOM or XOP.   We have taken the trouble to define the one
attribute, xmime:content-type that we feel will be of particularly general
utility;  we invite you and other members of the XML community to define
additional such attributes that may be necessary for purposes such as i18n.
We also note that the working draft at [3] says of the xmime:content-type
attribute:

"The [normalized value] of the contentType attribute information item MUST
be the name of a IANA media type token, e.g., "image/png", "text/xml;
charset=utf-16""

which specifically illustrates the use of charset.   We generally decline
to provide normative information in two places;  in this case, we think
that it's appropriate that use of the charset specification is indeed
documented with the normative recommendation for the xmime:content-type
attribute and not in xop or mtom themselves.  

5. The spec refers to URIs in several places. It is defined in the
XMLSchema to be of type anyURI, so we take this to mean the same thing
as the XMLSchema type anyURI. This type is actually more like an IRI and
we think it might be advisable to reference IRI somewhere.  There should
also be test cases for IRIs.  For example (assuming the actual document
is encoded in UTF-8), the following should be legal:

<soap:Envelope xmlns:soap='http://www.w3.org/2002/12/soap-envelope'
                xmlns:rep='http://www.w3.org/2004/08/representation'
                xmlns:xmlmime='http://www.w3.org/2004/06/xmlmime'>
   <soap:Header>
     <rep:Representation resource='http://example.org/写真.png'>
       <rep:Data xmlmime:contentType='image/png'>/aWKKapGGyQ=</rep:Data>
     </rep:Representation>
   </soap:Header>
   <soap:Body>
     <x:MyData xmlns:x='http://example.org/mystuff'>
       <x:name>John Q. Public</x:name>
       <x:img src='http://example.org/写真.png'/>
     </x:MyData>
   </soap:Body>
</soap:Envelope>

Also, the following should be legal:

<soap:Envelope xmlns:soap='http://www.w3.org/2002/12/soap-envelope'
                xmlns:rep='http://www.w3.org/2004/08/representation'
                xmlns:xmlmime='http://www.w3.org/2004/06/xmlmime'>
   <soap:Header>
     <rep:Representation resource='http://例.org/me.png'>
       <rep:Data xmlmime:contentType='image/png'>/aWKKapGGyQ=</rep:Data>
     </rep:Representation>
   </soap:Header>
   <soap:Body>
     <x:MyData xmlns:x='http://example.org/mystuff'>
       <x:name>John Q. Public</x:name>
       <x:img src='http://例.org/me.png'/>
     </x:MyData>
   </soap:Body>
</soap:Envelope>

6. How are the URIs matched?  For example, are they case-sensitive?  If
you take the two URIs/IRIs in the example above, Representation-resource
and img-src, then do the following pairs match? (here the image data is 
actually taken from the data in the header, rather than reported as 'not 
found'):

1) http://example.org/me.png         http://example.org/me.png
2) http://example.org/me.png         http://example.org/me.png
3) http://example.org/me.png         http://Example.org/me.png
4) http://example.org/me.png         http://example.org:80/me.png
5) http://example.org/~me.png        http://example.org/%7Eme.png
6) http://example.org/%7Eme.png      http://example.org/%7eme.png

These are only some of the simpler examples that are not clear at all.
Namespaces say that only 1) matches. RDF does the same. When actually
resolving, all of these will go to the same place on the same server.
So what happens in the case of this spec?


  

[NOTE: the issue has been reclosed after clarification of the following email,
 see below for further information]

point 5:
The following text was added to section 4.2.2:
<<<
The value of the resource attribute information SHOULD be a URI Reference 
as defined in RFC 2396 including ammendments to that definition found in 
RFC 2732.
>>>

point 6:
The following text was added in section 4.1:
<<<
URIs that are character for character identical MUST be considered equal 
when using a representation header to resolve a web reference; URIs that 
are considered equal according to the URI scheme of the URI SHOULD be 
considered equal.
>>>
Please note that the use of the Representation header does NOT mandate 
that its content is the authoritative representation of the resource. Nor 
what an application must do with it.

[Issue reclosed]
The XMLP WG decided to amend the text in Section 4.2.2 of the Resource
Representation SOAP Header Block as we discussed below. The editors
copy[1] reflects this change.
[..]

>  >Martin,
>  >
>  >Thank you for your detailed and comprehensive response. The current
>  >editors copy says:
>  >
>  >"The type of the resource attribute information item is xs:anyURI. The
>  >value of the resource attribute information item is a URI that
>  >identifies the Web resource whose representation is carried in the
>  >rep:Representation element information item parent of the resource
>  >attribute information item. NOTE: the use of the xs:anyURI type
>  >anticipates the possibility that in the future schemes will be developed
>  >that use IRI rather than URI naming for resources."
>  >
>  >I would be happy to change this to your text:
>  >
>  >"The type of the resource attribute information item is xs:anyURI. The
>  >value of the resource attribute information item identifies the Web
>  >resource whose representation is carried in the rep:Representation
>  >element information item parent of the resource attribute information
>  >item."
[..]

7. To avoid requiring that all SOAP senders understand the HTTP caching
mechanism, we recommend that all the data required by a processor that
wants to act as a local cache needs to be carried along with the
message. This includes the complete request/reply as well as the time
the original HTTP request has been sent and the time the HTTP response
has been received.

8. How are error conditions handled?  For example, what to do in the
case of an HTTP 404?
  

The XMLP WG decided to close issue 503 by taking no action, with the 
following rationale:

point 7:
The processing model does not mandate knowning the HTTP caching mechanism, 
the use of the enclosed representation is application depend. It may be 
used like a local HTTP cache, and the example in 4.3.3 is actually 
defining an extension to allow the application to use the enclosed 
resource representation as a local cache.

point 8:
It is up to the application to decide if the complete HTTP transaction (in 
that case, indicating that it resulted in a 404) is required, and it will 
then use an extension to carry that, or if the header will not be added.

2.1 Introduction
----------------

occurences => occurrences (2 places)
several representation => several representations


2.2.1 rep:Representation element
--------------------------------

"One or more attribute information items amongst its [attributes]
property as follows:"
=>
"One or more attribute information items amongst its [attributes]
properties as follows:"
(not clear as written, is it an "attributes property"?  If so, it can't
be "amongst" a single thing.  Same comment for section 2.2.4)

"One or more element information items in its [children] property in
order as follows:"
=>
"One or more element information items in its [children] properties in
order as follows:"
(not clear as written, is it a "children property"?)

"with a [namespace name] different than"
=>
"with a [namespace name] different from"


2.2.4 rep:Data element
----------------------
(Same comments as in 2.2.1)


2.3 Extensibility of the Representation header block
----------------------------------------------------
"several possible usage" => "several possible usages"


2.3.3 HTTP headers
------------------
"... all SOAP senders understand HTTP caching mechanism"
                                 ^the

  

Everything has been corrected in the latest editor's draft [1]. It was not 
possible to locate everything as you commented on a version that is not 
the CR version.

It would be very helpful if the MTOM spec had an example HTTP message in
it. This would help clarify that the MIME headers of the outer package
are sent as HTTP headers ( rather than as part of the HTTP entity body )
  

You raised an issue, 505[1] regarding the lack of an example in the MTOM
specification[2]. The working group have resolved this issue by
instructing the editors to add an example [to the primer] of an HTTP message
to the spec.

The examples in RRSHB use the namespace :
http://www.w3.org/2002/12/soap-envelope
for SOAP 1.2. This should be changed to the NS in the SOAP 1.2 
Recommendation, which is:
http://www.w3.org/2003/05/soap-envelope
  

The XMLP WG resolved issue 506 [1], which was raised through the email
at [2], during the 2004-10-06 WG telcon.
The WG decided to replace the incorrect namespace URI --
"http://www.w3.org/2002/12/soap-envelope" -- in the examples in RRSHB
[3] with the correct SOAP 1.2 REC namespace URI --
"http://www.w3.org/2003/05/soap-envelope".

The two examples in session "1.2 Example" show the one that Prior to
the XOP processing "look" shorter than the one apply XOP processing.
It is hard for reader to understand why using the XOP mean "more
efficiently serializing XML Infosets" if you show the one apply XOP is
LONGER in the example. (I understand what you mean there, but at frist
glance, the example show reader, the one prior tot he XOP is "more
efficiently serializing".
Basically, it is comparing Apple to Orange because the first one in
the example does not include HTTP header at all. To make it a fair
compasion could be done by replacing (or adding) the one which include
HTTP header but without XOP processing there.
  

You raised an issue[1] regarding the examples in the XOP specification. 
The XMLP WG considered your comment and have added the following text 
to the description of the examples:

"Note also that the sample base64 data is smaller than would be typical 
and the binary octets are not shown; in practice, the optimized form is 
likely to be much smaller than the original."