|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Data Model(s) for XML 1.0 / XML Devcon / DOM / XSL / Query
Sean McGrath wrote: > isn't it time to accept that not specifying formal > post-parse data model(s) for XML 1.0 was a big > mistake? To a degree. SGML made the same mistake initially - without ESIS and (much later on) groves, it was difficult to make much sense out of applications like HyTime. But the Infoset and the notion of a PSVI seem to address this issue pretty well, mostly. (As an aside, I fear that another lesson learned from the SGML experience is being forgotten. In SGML, validation was intimately coupled with parsing and processing. XML 1.0 largely avoided this problem, but the latest batch of Recommendations in the pipeline strike me as a bit over-reliant on XSD.) > Furthermore, would the members of the list concur > that there is an enormous difference between > the data model needed for read only apps and > the data model need for read/write apps. Yes, but there's also a huge difference between the data models needed for POP-oriented, MOM-oriented, and RDF-based applications, and a huge difference between the way XML applications written in Java, Perl, and Haskell will represent the data. I think the Infoset editors did a pretty good job coming up with a specification that's applicable to all of these categories. > Would the list accept that the read/write nature > of the DOM makes life overly hard for developers > of read only (and in particular persistent) DOM > implementations? No opinion here. (There are *other* aspects of the DOM that make life overly hard with the kinds of applications I usually work with, so I don't end up using it very often to begin with :-) > Finally, would the members of the list agree > that the read/write nature of XSLT is at the > heart of the difficulties in scaling its query > capabilities to the degree needed for purely > read only use such as is required by XML > Query? Not really. XSLT doesn't really have a read-write processing model. The input tree is never modified, and result nodes, once constructed, are never changed either. I think it's XSLT's flexibility that makes it difficult to optimize: since any template can potentially access any part of the source tree, predicting access patterns is very difficult. --Joe English jenglish@f...
|
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
|
|||||||||

Cart








