Re: question about XML protocol requirements

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

With the risk of stepping out of bounds (I'm not on this particular
committee) or repeating old posts, I'd like to suggest something related to
your question. I too spend time with other standards efforts, some of which
are tightly related to device networking (like printers).

Your question starts by discussing XHTML-Print, yet asks the question of XML
in a constrained environment. Rather than cover the former however, I'd like
to suggest that XML is a very convenient model for constrained environments.

Let's just take the SOAP model for discussion purposes. There is no
requirement, in any way shape or form, that an entire print document pass in
a single SOAP message. If appropriate to the standards body, a
query/response mechanism can (should?) be adopted. Any images not able to
fit in a single (non-chunked transfer) message would be passed across
multiple messages, either as a link to a potentially chunked transfer, or as
multiple query/response pairs. The latter, though, would require yet another
binary transfer protocol of which I'd not be a fan.

My suggestion here is that while XHTML-Print is interesting for memory and
CPU rich rendering devices, a SOAP (or XP) query/response protocol would
seem more interesting as a 'general purpose' model. The standards bodies I
work with generally have a goal of producing results sooner rather than
later, which is an agreeable goal, so as yet they, have not attempted to
construct such a model and have purposely shied away.

While such a model places more burden on the device requesting the print (or
any other rendering for that matter - such as streaming audio/video), we can
be relatively assured that that particular device will not be memory
constrained since it definitely must contain the document in question.

> Is anyone else looking at this problem?

The UPnP printing and Technical Committees are both spending plenty of time
on this issue.

Tom Hite


----- Original Message -----
From: "Herriot, Robert" <Robert.Herriot@pahv.xerox.com>
To: <xml-dist-app@w3.org>
Sent: Tuesday, January 09, 2001 3:41 PM
Subject: question about XML protocol requirements


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



_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

Received on Wednesday, 10 January 2001 10:15:34 UTC