[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: XInclude vs SAX vs validation
- From: David Brownell <firstname.lastname@example.org>
- To: Elliotte Rusty Harold <email@example.com>, firstname.lastname@example.org
- Date: Tue, 21 Aug 2001 10:43:51 -0700
> 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.
> However, I'm not sure if you can easily convince the validator to wait
> until you've resolved an include element before checking it. It may have
> already tried to validate just the one element before you get it.
Depends on the application. If the app's validity requirement is that
an XInclude element be found at some point, pre-XInclude validation
will be the answer. If the validity requirements are supposed to be
applied post-XInclude, it's a different story. I can create workflow
scenarios where either applies.