RE: XInclude vs SAX vs validation

[David Orchard <orchard@pacificspirit.com>]

On Tuesday, August 21, 2001 10:44 AM, David Brownell 
[SMTP:david-b@pacbell.net] wrote:
> > The only API that really works well for XInclude is DOM, because the
> > Infoset is in many ways designed around DOM and XInclude is designed
> > around the Infoset.
>
> Actually, SAX2 has ** MUCH ** better infoset support than DOM does.
> Yes, I've done the detailed analysis.
>
> If I were to say XInclude is DOM-oriented, it'd be because of that
> curious dependency on XPointer.  A C #include doesn't need access
> to partial documents; neither should an XML one!  XInclude seems
> more like a kind of link processor than a lowlevel #inclusion tool;
> it's not moved very far from its XLink roots.
>
>

This is puzzing to me.  A C #include doesn't need access to partial 
documents at least partly because it can't.  There is no syntax to express 
partial documents.  And it doesn't really need a syntax because the purpose 
of #includes is file modularity.  But XML modularity is at the file, ele  
ment and attribute modularity.  In fact, I would argue that XML's raison 
d'etre (sp?) is to give people a regular syntax at a finer granularity than 
#include, etc. support.

And how could XInclude be lower?  XML 1.0 is fixed in stone.  To make 
XInclude lower level, we'd have to break xml 1.0 compatibility.  There's no 
way we could make an XML 1.1 that broke XML 1.0 compatibility.  So after 
XML 1.0 processing is done, all a parser has is an infoset.  So Xinclude 
has to work on an infoset.

Cheers,
Dave Orchard