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

RE: question about XML protocol requirements

From: Herriot, Robert <Robert.Herriot@pahv.xerox.com>
Date: Wed, 10 Jan 2001 19:06:00 -0800
Message-ID: <51B8ABCE456FD111899900805F6FD6EE0A34EB69@mercury.ADOC.xerox.com>
To: "Thomas D. Hite" <tdhite@yahoo.com>, xml-dist-app@w3.org
I don't think that SOAP solves the problem.

The problem, as I understand it, is that the XHTML-Print document needs to
be split into several fragments so that binary images can be interspersed
between XHTML-Print fragments. The problem is that each XHTML-Print fragment
is not well-formed. Only the concatenated contents of all the XHTML-Print
fragments is well-formed. 

I think that such a solution implies new Content-Types and rules for
assembling them.



> -----Original Message-----
> From: Thomas D. Hite [mailto:tdhite@yahoo.com]
> Sent: Wednesday, January 10, 2001 9:18 AM
> To: xml-dist-app@w3.org
> Subject: 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 22:06:04 GMT

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