[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Simple approaches to XML implementation
[F. Chahuneau, 01 Mar 1997] > >All in all, you can see that some design decisions in XML were precisely > >motivated by the desire to make an ESIS event stream sufficient to > >implement an identity transformation, even with no access to DTD > >information. This is, of course, totally consistent with the idea that > > DTDs should not be systematically needed for processing XML fragments. > [Tim Bray Sat, 01 Mar 1997] > Whereas I agree with the rest of Francois' contribution, this paragraph > is not quite right. If you change "ESIS event stream" to "Instance > character stream", then it would be more correct. But in fact the > SGML->SGML declaration was not one of our goals; for example, the > processor is not required to tell the app about [at least] comments > and <![CDATA[ sections. The XML spec says *nothing* about the ESIS, > merely, in a very abstract way, what the processor has to give the > application. > (Hello, Tim) I suspect we actually agree more than it seems, but I should not have used the term "identity transformation" without defining it first. My implicit definition was very minimal: being able to generate on the output side an instance which parses according to the same DTD as the instance on the input side. As you know, not being able to detect EMPTY elements defeats this purpose, whereas not knowing whether an attribute was defaulted or not, though it might be considered as an information loss, is not a problem according to this definition. As many other SGML practicioners, I've never considered the fact that CDATA marked sections (or comments) would not be notified to be as important in practice as the previous problem. (From an abtsract point of view, marked sections can be seen as a packing scheme allowing to deliver several "abstract trees" interleaved in a single file... and therefore are not representable on a single abstract tree. (Maybe this means I have been thinking in an XML-oriented framework even before it was formalized... which is probably why I supported the idea so readily!) Anyway, I will not pursue (at least not here) this dicusssion which probably deviates from the main purpose of this list. I provided some precise information about ESIS because the subject was raised, but it is clear that its only utility, in this discussion, is to serve as an example of a normalised "event-stream based" interface between a parser an application, which could inspire more carefully designed interfaces in the same style. A tool such as Balise, in its communication with SP, requires more than ESIS... The only important message, in all what I said in my previous e-mails, is my conviction that a useful API should provide both event-stream *and* tree-manipulation paradigms. It is true, to some extent, that you can build one from the other, and that this could be done inside the application. But implementing this duality *below* the API level offers big advantages, both for maximum expressive power/flexibility ... and to avoid everybody to reinvent the wheel. [Peter Murray-Rust Sun, 02 Mar 1997 11:32:40] > My own development depends to a significant extent on what API I can > use after parsing.I want it to be very clearly separated, because I > see a parser as being a 'bolt-in' tool rather than a component which > drives the rest of the application. (Maybe this isn't possible, but it's > worth trying for). This is indeed possible and, to my opinion, it's even required. This is how Balise is implemented, both with respect to both SP (the SGML parser module) and to its new XML "well-formed document scanner" module. The parsing module should be able to operate in "slave mode", and this should be reflected at the API level (i.e. you need a primitive to trigger the parsing of an SGML document or an XML fragment). This also means you need the parser to be reentrant. That was not the case with sgmls, but it was fixed with SP, and should not be too hard a requirement for the forthcoming generation of XML parsers/scanners. _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ _/ François CHAHUNEAU phone: [+33] 1 40 64 43 00 _/ _/ Directeur Général/General Manager _/ _/ AIS S.A. FAX: [+33] 1 40 64 43 10 _/ _/ 15-17 rue Rémy Dumoncel email: fcha@a... _/ _/ 75014, Paris, FRANCE WWW: http://www.berger-levrault.fr _/ _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ xml-dev: A list for W3C XML Developers Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To unsubscribe, send to majordomo@i... the following message; unsubscribe xml-dev List coordinator, Henry Rzepa (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
|