XMLP Issues 406, 407 and 408 Closed

Susan,

Thank you for your careful review of parts 1 and 2 of the SOAP 1.2 
specification. The comments you raised formed XMLP issues 406, 407 and 
408 [1][2][3]. The XMLP working group considered your issues in a 
recent telcon and assigned the editors to work through your comments 
and close the issues.

The editors have incorporated the vast majority of your suggestions 
(see detailed comment dispositions below) and now consider these issues 
closed.

We hope this satisfies your concerns, please let us know if not by 
replying to this email making sure to CC xmlp-comments@w3.org.

Regards,
Marc (on behalf of the XML Protocol working group)

[1] http://www.w3.org/2000/xp/Group/xmlp-cr-issues.html#x406
[2] http://www.w3.org/2000/xp/Group/xmlp-cr-issues.html#x407
[3] http://www.w3.org/2000/xp/Group/xmlp-cr-issues.html#x408

--
Marc Hadley <marc.hadley@sun.com>
Web Technologies and Standards, Sun Microsystems.

A detailed comment disposition follows.

> The files would be 10% smaller if run through HTML Tidy with indent 
> off.
> http://tidy.sourceforge.net/
>
Not done on the editors copy but can easily be done for the next 
release.

> Please remove this CSS rule to fix display in Mac IE and Opera:
>
>      dt.label       { display: run-in; }
>
Done.

> 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.
>
Removed. It did come with the xmlspec.xsl we are using.

> 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
>
Summary attributes are a level 3 requirement and are not required for 
Level A compliance. Most tables have captions for descriptive purposes.

> 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]/
>
All done.

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

> 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&eacute; de France])/
>  s/Hewlett Packard/Hewlett-Packard/
>  s/Developmentor/DevelopMentor/

All done.

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

> In 1.5.1, s/SOAP Module/SOAP module/
>
Done

> 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.
>
Done.

> 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).
>
Done.

>   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/

Done, although just decapitalized NOT rather than added bold.

> In the Abstract, s/Part1/Part 1/
>
Done

> 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.
>
Done

> 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]).
>
Left at 1.0 for now. May be updated later depending on timing.

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

> 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.
>
Done.

> 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/
>
Done.

> "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/
>
Done, added an informative reference.

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

Received on Wednesday, 12 February 2003 15:31:34 UTC