[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: XML API specification
At 9:19 AM -0500 2/27/97, Gavin Nicol wrote: >I think that for the *parser*, we should define an event-handling >interface, as it is much simpler to build certain applications >that way, and because you can build a tree from a stream of >events if you need to. Funny, that is exactly what I was thinking. Since reading the design patterns book, I've become quite fond of the "Builder" pattern, where some process like a parser takes as input an object whose methods perform appopropriate processing as the input is recognized. It's even possible to use Builders with things other than parsers, as long as they make the same callbacks. The real advantage of such an interface is that we don't impose a data structure on an application that might not want it. For instance, many functions are easier if you have an abstract syntax tree, but some quick and dirty applications won't need an AST, nor will they want to take the memory hit of building one if they don't need it... <digresion type="Possible use of extra abstraction"> It might also be of use to define a callback interface that allows automatic delegation of building for certain elements. To be non-cryptic, I can see an application for a standard interface to java applets that will automatically delegate the processing of the events representing a particular sub-trees of the document to a particular applet. For instance, the default Java applet interface might allow a document to declare that <interaction-graph> elements should be processed by the class "InteractionGraph.class" This would cause the Builder implementation to auto-invoke the Applet for the parser events in each interaction graph, and then would pass the Applet instance to the main application, in place of its contents. Think of this as (slightly goofy?) event-driven compound document renderings. </digression> >Some questions that will affect the API is whether one sees empty >element as elements containing nothing, or as elements unable to >contain anything, and wether entity/attribute type information needs >to be passed across thr API. > >What do people think? How much information must the parser pass >along? > All that information _must_ be available. The chief reason that I find ESIS useless is that I can't write SGML->SGML transformations without complete information. We should have as a goal that an identity transformation whould be possible. By Identity, I only mean to require equivalence up to "insignificant" whitespace normalization. I.E. We should be able to produce an instance lacking no information that the standard does not explicitly label insiginificant. We should have a way for a builder to signal its controller that information such as entity boundaries, and maybe some DTD info, is _insignificant for that execution_. I suppose a more-general thing would be to register the events that you are interested in -- and others would simply be silently ignored. This could be handled by having empty default implementations, so it may not require special handling. As to languages, I am sympathetic to the IDL argument, but I have a few practical notes: It seems that already more people know Java than IDL. IDL information seems to cost money. As to principles for making a decision: * Platform independence seems a hard requirement: in favor of both Java and IDL, against OLE/Active-X/other proprietary gunk. * Language independence is good (but not quite a hard requirement): This is a point in favor of IDL, but I think that many will be learning IDL by comparing the Official Standard against the Java binding produced by the nifty tools... In other words, if the IDL folks can write the syntax up and post the processed Java bindings here, we should do IDL, otherwise java is good enough, and the inverse binding -- though inelegant -- can be created later. -- David _________________________________________ David Durand dgd@c... \ david@d... Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ 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
|