Re: RS/RE, again (sorry)

I asked:

| >[Chris Maden:]
| >
| >| 3) A dichotomy between "DTD-ful" and DTD-less parsing will make any
| >|    sibling-based relationship difficult at best; this will affect some
| >|    TEI or HyQ based hyperlinks, as well as sibling-based stylistic
| >|    decisions.
| >
| >Sorry to be so slow here, but what's the connection with sibling
| >relationships?  My idea of a well-formed XML document is one for which
| >there is just one possible tree structure; what's different about
| >sibling relationships if a DTD is provided?

To which a kind correspondent replied:

| A DTD-less parser will interpret element-content whitespace as a #PCDATA
| node. A DTD-full parser will just strip it out. The number of nodes in your
| document will change.
| 
| <LIST>
| <UITEM>...</UITEM>
| <UITEM>...</UITEM>
| </LIST>
| 
| Each newline will be a node in one, and not the other.

Allow me to wallow in ignorance a bit further.  I'm finding it hard to
visualize a situation in which I would want to address something based
on pseudo-element relationships rather than "genuine" tree
relationships.  It's easy to imagine cases where I would want to refer
to the TITLE descendant of my ancestor CHAPTER, for example, but I
have never wanted to refer to the third linefeed in an element.  I'm
not saying that such situations are inconceivable, I'm just saying
that I've never encountered one.  Is this one of those cases where 90
percent of the complexity we're worrying about is being caused by a
feature that in practice is used .001 percent of the time?

Jon

Received on Tuesday, 17 December 1996 14:47:58 UTC