W3C home > Mailing lists > Public > xml-dist-app@w3.org > May 2004

Re: Request for review: XOP

From: <noah_mendelsohn@us.ibm.com>
Date: Mon, 3 May 2004 18:56:04 -0400
To: Elliotte Rusty Harold <elharo@metalab.unc.edu>
Cc: Robin Berjon <robin.berjon@expway.fr>, www-dom@w3.org, XMLP Dist App <xml-dist-app@w3.org>
Message-ID: <OFC31EF02E.9AB56B80-ON85256E89.007CEE5B@lotus.com>

Speaking for myself, the API's I would consider would in fact be general 
to all of XML, but they would optimize particularly well when used with 
XOP. The sort of thing I would have in mind would be along the lines of 

        // given a binary octet stream, create a text node consisting
        // of the characters representing the xsd:base64Binary
        // canonical lexical representation of that stream
        Text t = createBase64TextfromBinaryStream(binStream);

        // inverse of the above, retrieves the stream
        OctetStream recoveredStream = parseTextasBase64Binary(t);

        // the following is usable anytime after the creation
        // of t.  In an optimized implementation, the
        // character form won't actually be computed
        // unless a method like this is called.
        String base64 = t.data();

This would create a text node with the base64binary coding of the 
corresponding stream.  I'm not a DOM expert, so excuse any errors of 
detail.  Perhaps CharacterData would have been a better node type than 
Text, I'm not sure. 

As you can see, this is general to XML and not specific to XOP.  The 
reason it's important for XOP is that optimized implementations can defer 
generation of the actual characters until they are actually requested. 
With XOP, there will be important cases in which the characters will never 
be inspected.  In particular, if the document is to be serialized as XOP, 
then parseTextasBase64Binary can merely reference or copy the original 
supplied binStream.  That's the optimization we're hoping to get for XOP: 
the characters are there in principle but in important cases,  nobody asks 
for them and you never actually generate them.

In any case, I don't think anyone is proposing a DOM API that would 
manipulate XOP at the multipart level.  Again, these are my personal 
opinions;  others in the XMLP wg may agree of disagree.

Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
Received on Monday, 3 May 2004 18:58:33 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:12:03 UTC