Documents and Document Fragments

Mark Birbeck Mark.Birbeck at
Wed Feb 24 19:58:07 GMT 1999

> -----Original Message-----
> From:	Tim.Shaw at [SMTP:Tim.Shaw at]
I maybe don't quite understand this - my apologies if I'm missing

> A document fragment is a lightweight document (as defined by W3C 
> REC-DOM-Level-1-19981001). These fragments may be used for numerous
> purposes - 
> including creating (by 'insertion') other documents.
> A document fragment need not be WF - but (presumably) they must
> represent at 
> least one <tag></tag> type construct as they are also Nodes
	In terms of the DOM-view of fragments, it doesn't even have to
have <tag></tag> because the fragment could just be text. It must be a
well-formed entity, although it needn't be a well-formed document (like
if it's just text.) In terms of an external view of fragments - say
TR/NOTE-XML-FRAG-REQ - then conformance is to XML 1.0 [43] - which also
could be just CharData, and again, the fragment must be a well-formed
entity, but not necessarily a document. I separate the two views though,
because I feel the terms represent two different concepts, in their
separate contexts, as I'll try to explain.

	The discussion of 'document fragments' in say
TR/NOTE-XML-FRAG-REQ talks about how to provide the context for a
fragment. Most of the discussion on this list so far has talked about
fragments as things like:

		<para>Here is the news</para>

	As I said in a previous message, I can see value in this
definition once you are inside the parser - or from the point of view of
the DOM - because it means you can refer to subsets of the document,
move things around, and so on. But inside the DOM you have context; the
fragment has parent information, you have the DTD to which it conforms,
and so on. The fragment never exists 'independently' of its owning

	But what if that fragment wants to venture out into the big wide
world of the Internet. Your news item wants to appear in my list of
stories of the day. Then in implementation, I think you have to end up
back at the notion of a document. I can't see how you could pass around
a fragment between applications without something like:

			<elementType type="newsfeed" id="item1">
				<elementType type="para" id="para1">
					<elementType type="CDATA">
						Here is the news

	OK, I made all this up, but what I'm showing is how the context
in which 'Here is the news' appears on the news server has been passed
to the receiving application. Now I can have a DOM for my news page,
request your news item, create a DocumentFragment as defined in DOM from
what I receive, and then insert it into my news document.

> Surely it's down to the parser as to whether you can access these
> things before 
> the XML document has been fully parsed (and they are _not_ Valid XML
> 1.0 
> documents(?)). The parser can still be XML 1.0 conformant - but it
> would need to
> provide non-conformant interfaces to allow interim access.
	I think this is talking about different things. Of course if you
write a parser you can do anything you want with the data, but what I'm
banging on about is whether you are keeping within the principles of XML
when you start to provide 'non-conformant' interfaces, 'interim access'
and such like. It seems to me that the notion of a document that has
been confirmed to be well-formed - and possibly validated - is a
fundamental unit of what we call XML. Beyond that, applications,
features, enhancements, etc., should be considering implementation on
top of that unit, not smashing it. I just can't get with the notion of
something that's 'XML 1.0 conformant' that can process non-well-formed

	So, to summarise; I think 'fragments' is a useful term when
inside the parser, because there we can deal with real fragments.
However, we cannot pass a parser anything less than an XML document
(without going against XML 1.0) and so although outside the parser a
'fragment' is a useful abstraction, in reality one cannot exist outside
a well-formed document.

Yours, probably a bit pedantically,


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

More information about the Xml-dev mailing list