[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: Streams, protocols, documents and fragments

  • From: "Borden, Jonathan" <jborden@m...>
  • To: "Nathan Kurz" <nate@v...>, "xml-dev list" <xml-dev@i...>
  • Date: Tue, 23 Feb 1999 21:44:42 -0500

define long document
>
>
> Jonathan Borden writes:
> > <term>document</term> is defined as in the XML spec. documents are well
> > formed. when a document fragment is isolated from its parent
> document, it
> > becomes a standalone document.
>
> Sounds fine so far...
>
> > a document may contain a prolog. a document fragment may not. a
> document may
> > contain a !DOCTYPE definition (DTD), a document fragment may
> not. Hence all
> > document fragments are legal documents but not all documents are legal
> > document fragments.
>
> I think I follow what you are saying, but I'm confused why you would
> choose to define a document fragment in this way.  Why can't it
> contain a prolog?

	because then it is a document. My sole purpose in discussing 'document
fragments' was because the thread had gotten stuck on the notion that a
continuous XML stream would contain a single long document (perhaps w/o a
closing tag) and the actual PDU's consist of document fragments ... the
point is that if we create a protocol on a stream which transmitts multiple
documents, there is no loss of functionality over a solution employing
'document fragments'

> Are you assuming that document fragment must be
> produced as a reduction of a parent document?  It strikes me as very
> odd to define 'document fragment' as a superset of 'document'.

	to the contrary, if all legal doc frags were in fact docs then doc is a
superset of doc frag ... but it has been pointed out that doc frags aren't
always legal docs (when non default charsets are used).

>
> > So, the problem here is not one with XML, rather the protocol used to
> > transmit documents, HTTP and SMTP send one MIME message per
> PDU, streaming
> > protocols can be defined which transmit multiple documents.
>
> But the definition of XML processor does become a problem here.  If
> the stream consists of multiple XML documents, one must use an
> XML-aware processor to parse it.  But this had better be a
> non-conforming XML processor, since according to the spec a
> 'conforming XML processor' must cry foul if its input doesn't have one
> and only one root element.
>

	It is the responsibility of the *protocol* to pass a document to the XML
parser. There is no requirement that the stream be passed unadulterated to
the XML parser. The suggestion of delimiting characters allows the protocol
layer to easily chop the stream into individual documents.

Jonathan Borden
http://jabr.ne.mediaone.net


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i...
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo@i... the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@i... the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@i...)


PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.