Re: XInclude vs SAX vs validation

[David Brownell <david-b@pacbell.net>]

> > XInclude could become "low level" by dropping the dependency
> > on XPointer.  The Infoset dependency is no problem (to me :),
> > but the XPointer dependency changes things substantially; it's
> > relying on a lot more than XML 1.0 plus infoset.
> 
> Gotcha.  You mean "low level" in the sense that the burden of 
> implementation is lower.  I was thinking you meant low level as in working 
> "lower" in the stack, ie not on infosets.

Infoset is low level; XPointer isn't.  I was most certainly
talking about low level as in "low on any layer cake picture".

XPointer is stacked on top of at least XPath and some data
structure machinery that would otherwise not be needed.
To repeat, Infoset is not the issue, unless there's some kind
of expectation about how it's represented (say, that it's set
up for random access).


> FWIW, there's been some debate about the utility of XInclude refering to 
> XPointer'd thingies.  I personally think it's a reasonable compromise 
> between providing file modularity (what you are proposing) and a complete 
> entity replacement (what others have advocated).

Eh?  External entities _are_ at the file level.  There's no need to
compromise between those two things, they're the same notion.
Using XPointer is going off towards XLink.


> But I do understand your point about the amount of machinery being higher 
> to support these use cases.  I would argue that if most xml parsers support 
> xpointer, 

Big "IF"; none do, AFAIK.  Even the DOM Level 3 proposals for
optional (!!) XPath modules stop short of XPointer support; not
that a DOM XPointer module would count as "low level" to me
(being able to count way too many layers between the XML and
the top of that particular stack :).

- Dave