Proofread of XOP draft

With apologies for not having gotten to it until the last minute, I've done
a readthrough of the XOP draft.  I understand that there may not be time to
consider the following prior to last call, but I think at least some of
these might merit attention.  They're sorted roughly into most important,
less important, and editorial.  I haven't gotten to MTOM yet, and I'm at
www2004.  I will try to find some time before tomorrow's call to read and
enter comments on that, but it looks unlikely I'll manage it. Maybe someone
else can find the time to doublecheck it?

Most Important
--------------

* Section 1. The intro currently says: "When XOP is used as intended,
binary data will never be encoded in base64 form. Indeed, to add binary
data into an XML Document, a XOP-aware application will add the linking
element at the correct location in the XML and place the binary data
directly into the package. "  That seems too strong, as we do intend that
the characters be made available in a variety of situations including dsig,
re-encoding into XML 1.0, etc.  Furthermore, I strongly object to the
suggestion that applications directly create xop:include elements, as this
is quite likely to be done by middleware.  How about:  "In a number of
important XOP applications, binary data need never be encoded in base64
form. If the data to be included is already available as a binary octet
stream, then either an application or other software acting on its behalf
can directly copy that data into a XOP package, at the same time preparing
suitable linking elements for use in the root part;  when parsing a XOP
package the binary data can be made available directly to applications, or
if appropriate, the base64Binary character representation can be computed
from the binary."

* Section 3:  Suggest changing "An informative XML Schema" to "A
non-normative XML schema".  I hope it's informative either way, but the
point is that it is not normative.   Any reason not to just say that?

* Section 3.2: see emails from me and from Gudge suggesting that we
reference Schema datatypes anyURI for the lexical form of the content of
the href attribute.  I'm offline and don't have the archive link, but mine
was sent on Tues 5/18.

Less Important
--------------

* Section 1. The introduction doesn't mention xop-mime:content-type.  This
seems to be a significant function, since it is for use in user content as
opposed to just in the xop internals.  Should we not set it up with a
sentence or two of introduction?  Perhaps something like:  "This
specification also introduces an attribute xop-mime:content-type which may
be used in XML documents to indicate the media type of base64Binary
content.  XOP uses this attribute, if present, to provide suitable typing
for MIME multipart/related parts."

* Section 1.1 Note:  "Mark proposes to change "any W3C recommendation-level
version of XML" to "XML". The current text comes from the resolution of
rec20 and rec22. Do we want to change it? "  I'm inclined to keep it as is.
I'm not sure that "XML" unqualified is sufficiently unambiguous.  I'm not
arguing that it's actually wrong, but I think we will get questions from
users asking:  can I use XML 1.1?  Why not provide an answer in advance?
See also item 1 in the instructions for reconstituting in section 4.2,
which makes the connection from XML declarations to levels of the XML
Recommendation.

* Section 2:  "The subsection below specifies how a particular packaging
mechanism, MIME Multipart/Related, is used, but does not preclude the use
of other packaging mechanisms with the XOP convention."  I suggest adding
the word normative as follows: "The subsection below specifies
>normatively< how a particular packaging mechanism, MIME Multipart/Related,
is used, but does not preclude the use of other packaging mechanisms with
the XOP convention. "  Reason:  without this, it all seems sort of vague.
You can do whatever you like.  With this, it makes clear that there is a
normative multipart representation with conformance requirements specified
in the rec.  Indeed, you can also use XOP as a framework for inventing your
own, but the rules for building a multipart are normative when that's what
you decide to do.

* Section 5:  "Note that there is currently no convention for structuring
XOP-based media types." -> "Note that there is currently no convention for
structuring >the names of< XOP-based media types. "  Reason:  this whole
rec IS about conventions for structuring XOP media types.

* Section 6:  "The integrity of XOP Packages may need to be ensured. As
such packages can be transformed to an XML Information Set, existing XML
Digital Signature techniques can be used to protect such packages. " ->
"The integrity of >Infosets optimized using XOP< may need to be ensured. As
XOP  packages can be transformed to recover such Infosets (see section
4.2), existing XML Digital Signature techniques can be used to protect such
them.  Note, however, that a signature over the Infoset does not
necessarily protect against modifications of other aspects of the XOP
packaging;  for example, an Infoset signature check might not protect
against an exchange of position of two non-root parts.  To protect against
such modifications, the serialization of the multipart related or other
package would have to be signed, but no standard means is here proposed for
computing package-level signatures."  Reason:  should be self-explanatory.
DSigs over the infoset DO NOT protect the package, and one can imagine
situations in which protection of the package is needed.  In any case, we
should be careful in making such claims.

Editorial or minor
------------------

* Section 1. "In the reverse direction, XOP only allows to extract from an
XML Infoset base64-encoded data that is in the canonical lexical form. "
-> "In the reverse direction, XOP is capable of optimizing only
base64-encoded Infoset data that is in canonical lexical form."

* Section 3. "Infoset containing such element information item cannot be
serialized using XOP. "  -> ">Infosets< containing such element information
>items< cannot be serialized using XOP. "

* Section 3.1. "There MAY be zero or more namespace qualified element
information items in its [children] property. Any such element information
item MUST have a [namespace name] different of
"http://www.w3.org/2003/12/xop/include". "  I suggest: "There MAY be zero
or more namespace qualified element information items in its [children]
property. Any such element information item MUST have a [namespace name]
and that name MUST NOT be "http://www.w3.org/2003/12/xop/include". "

* Section 3.1: Suggest:  "Any other namespace qualified attribute
information items with a [namespace name] different of
"http://www.w3.org/2003/12/xop/include". " -> "Other attribute information
items; these MUST have a [namespace name] the value of which MUST NOT be
"http://www.w3.org/2003/12/xop/include"."

* Section 5: "To enable applications to identify the use of XOP as well as
the original Infoset's media type, formats wishing to allow XOP
serialization MUST register a distinct media type that identifies the
format of the XOP Infoset."  I think it's a bit clumsy to imply that
formats can wish for things.  How about: "To enable applications to
identify the use of XOP as well as the original Infoset's media type, a
distinct media type MUST be registered for each application of XOP to a
particular XML application vocabulary."

* Section 5: "For example, if the format identified by
"application/soap+xml" wishes to enable applications to identify XOP
serializations, it MUST register a XOP-specific media type (e.g.,
"application/soap_xop+xml")."  for the same reason I suggest "For example,
if the format identified by "application/soap+xml" is to be packaged as XOP
serializations, then a XOP-specific media type (e.g.,
"application/soap_xop+xml") MUST be registered. "

Notwithstanding the above comments, I think the recent draft is overall
really good.  Thanks to Herve and Mark, who I believe are responsible for
most of the hard work on this.

--------------------------------------
Noah Mendelsohn
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------

Received on Tuesday, 18 May 2004 22:49:24 UTC