W3C home > Mailing lists > Public > xml-dist-app@w3.org > January 2001

question about XML protocol requirements

From: Herriot, Robert <Robert.Herriot@pahv.xerox.com>
Date: Tue, 9 Jan 2001 18:41:22 -0500 (EST)
Message-ID: <51B8ABCE456FD111899900805F6FD6EE0A34EB15@mercury.ADOC.xerox.com>
To: xml-dist-app@w3.org

I have a question about the work on XML protocol requirements. 

I am working with several standards groups that defining  XHTML-Print, which
is XHTML-Basic plus a few page related features. XHTML-Print needs to be
able to reference non-XML data, such as jpeg images.

Your document states in R700a that ebXML and RosettaNet are solving the
problem of binary data in XML and the W3C XML Protocol Group is not. Those
groups both solve the binary-data problem with multipart/related.

We have considered a similar solution for XHTML-Print, but we have one
additional constraint that is not addressed by the ebXML or RosettaNet
solutions. Some printers have only enough memory to hold a page or two of a
document stream. Such a printer must be able to obtain an image from a
nearby place in the document stream; it cannot read through and buffer an
entire XML document before finding the image. 

Is anyone else looking at this problem? 

Ideally there should be less than one printed page of XML text data between
an image and its reference. In the context of multipart/related This
constraint seems to imply that:

a) the XML text data must be split into multiple fragments with one or more
images between each XML fragment, 
b) there must be a root object that references all of the XML fragments with
cid's
c) images must be referenced with cid's within the XML fragments. 

The XML-fragment concept may have problems because the XML is not
well-formed until all fragments are concatenated.

I would appreciate your thoughts on images and XML in a memory constrained
environment.

Bob Herriot
Received on Wednesday, 10 January 2001 05:24:09 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:58:58 GMT