Re: Proposed process for DTDs in XML (Implementations)
I've divided this response into two pieces. This one addresses potential implementations using SAX. Peter Murray-Rust wrote: >SAX and the DOM co-exist very well - I have >had feedback in-real-life saying that SAX was exactly what they wanted and >the DOM was too large and confusing. Similarly I can see that 'XMLDTD' (or >whatever) could find a useful niche. This seems like the right model, especially since I suspect the DOM is gaining to some extent from the experience of developers who have cut their teeth on SAX and are ready for more power. >Because SAX was the first API for >XML, David and we had to face *generic* problems that hadn't been foreseen, >particularly Exceptions and encodings. >[...] >One fundamental aspect is whether there needs to be any software or >APIs. Although theoretically SAX could have been written as an API, in >practice it was critical that David produced an implementation as proof of >concept. (and also for 'marketing'). I feel strongly that this project will need an implementation, though I also fear that I'm not a good programmer to execute it. I'd like to see the implementation built on SAX if possible, to continue the tradition of openness it began. I can see something like a 'validating SAX', (vSAX?) a program which uses the SAX API to parse a DTD (or whatever we call it) and then uses SAX again to parse the document, validating it against the DTD. vSAX would then use the same SAX API to pass the information to the routine which called it in the first place. Applications already using SAX could call vSAX without having to make many changes. This may go beyond the capabilities of the event-driven model. Building this project in such a way that the vSAX parser could validate documents without having to build an entire tree would likely warp the DTDs dramatically. That could be interesting, but I suspect vSAX would have to build a tree internally. Originally, I felt that a specification with a syntax and test cases would be sufficient. I still suspect it should be, but an implementation would be useful to check the spec and provide a fundamental set of tools for interoperability. My Java experience is unfortunately weak, more suited to the integrator's task of plugging things together (my job until recently) than building elegant structures. This is more than a simple integration. I'd like very much to participate, but don't think I can do this myself. Volunteers? >It may even be that we preprocess these XDTDs to conventional >DTDs. After all there will have to be *some* processing machinery for them, >even if it's only an XML parser and a transformation engine. This would be another possible and simpler implementation - a converter. Is it compelling enough? >I am assuming that part of the result will be the ability to express a DTD >(or equivalent) in XML syntax. That means it can be held as a tree. In that >case JUMBO (and many other tools) will naturally be able to hold the result >in memory and to display it in a variety of ways. So, to the extent that >that is useful, I can hopefully commit to being able to provide it. That's another useful piece, certainly - a key step toward making this more usable. Simon St.Laurent Dynamic HTML: A Primer / XML: A Primer / Cookies xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@i... the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...)
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