Re: Proofread of XOP draft

noah_mendelsohn@us.ibm.com wrote:

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

I agree.

> * 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?

I agree, need to do this also in Table 1 and in MTOM.

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

I agree in general, but think we should add a reference to RFC 2732 in 
our spec.

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

 From my understanding, xop-mime:content-type will be specified outside 
of XOP. (in the WSDL Media Type document), therefore we probably should 
replace 3.3 by a reference to the current draft of this document.

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

I'm also inclined to keep it as is.

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

OK.

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

OK.

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

OK.

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

OK.

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

OK.

> * 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". "

OK.

> * 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"."

OK.

> * 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."

OK.

> * 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. "

OK.

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

You're welcome!
Thank you for your comments.

Hervé.

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

Received on Wednesday, 19 May 2004 11:24:50 UTC