[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: XInclude vs SAX vs validation
On Tuesday, August 21, 2001 10:44 AM, David Brownell [SMTP:david-b@p...] 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
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|