[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: XInclude vs SAX vs validation
- From: David Brownell <email@example.com>
- To: firstname.lastname@example.org
- Date: Tue, 21 Aug 2001 11:51:19 -0700
> > 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.
Actually my understanding is that it was part of a historical context
of composing bigger documents from smaller ones. The "partial
documents" in question were always files/documents. (XML seems
to partake of that context, fwiw.)
> There is no syntax to express
> partial documents. And it doesn't really need a syntax because the purpose
> of #includes is file modularity.
As I'm saying the purpose of XInclude should be. It's certainly
suggested by the name's analogy to #include.
> 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.
It's a pretty huge leap to say that, for example, C/C++ doesn't have syntax
or modularity below the file level. Functions, statements, blocks ... analogies
to XML are easy to see, and there are many more. But they're only referred
to from other "compilation units" (files) by a linker (ok, an XLink ref! :).
> 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.
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.