[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: XML Property Set
> > |---------------| > | Grove API | <<< I assume this has similarities to JamesClark's > |---------------| ReallySimple API ... I'm not certain what the ReallySimple API is. I was think along the lines of the DSSSLTK dsssl.grove package. > | Grove Builder | > | API | <<< different memory/storage models are implemented > here. Yes, exactly. The Grove API is abstract and the Grove Builder API hides the exact implementation methodologies for constructing grove objects from the rest of the world. > |----------------------------------| > | XML Event API | << presumably fairly similar to > NXP? Potentially. I assume there will be some "grand convergence" on this between parsers and the needs of a grove. > |----------------------------------| > | XML Parser API | << Corresponds to John Tigue's > analysis? > |----------------------------------| Yes, and maybe more infrastructure if we are up to it. IMHO, this API should provide the ability for different parsers to be *configured* for use within an application. Hence, this should be an abstract component that is complete enough to allow most (if not all) applications to not have to know the implementation details. We could use a factory design pattern here. > I guess the two bottom layers and the connection between > Event API and Grove Builder API are my call. Potentially. I would guess that there could be a reference implementation of an event handler that "knows" how to interface a grove builder. It is probably not true that *all* grove builders can be accessed the same. For example, in a database situation, extra work may be necessary in the connection of the events to the grove builder. > Let me ask you : > > Should we go for a pure event oriented API, like it is now > implemented in NXP (and leave it up to the next layer to create the > objects) or should we have creator methods that would be set in the > event > API like now the Esis object is set (setEsis) in the parser. These > methods > would be called in case of a specific event and the result of this > method call would be send to the application via the event interface. I think the event API is the most abstract and lowest level for a parser. In this manor, applications that do not need "grove objects" will not have to have them created within some implementation. SP, for example, has quite an extensive event-oriented API. Each event has a great deal of detail (basically, everything there is to know). It is fairly easy to access the high level semantics of these events. Low level semantics like document strings--character for character representations of the event--are a littler more work. This is a design decision that we have to make. We could have two event APIs--one for document string access and one for high level access including document string information, but that could get far to complex. One might also beg the question of why we need the document string separated out when you can get it from the high-level events. > > For instance we would have an interface : > > public interface Constructors > { > public Element createElement(); > public Attribute createAttribute(); > ... > } > > Element and Attribute etc. will probably be subclasses of Node, > as per James' simple API. Node, however, should be defined > very generally so that we don't *have* to think about > DSSSL when want to talk about/use a node. > > An event-producer class conforming to the Esis(++) interface would need > to > implement a method : > > public void setCreator(Constructors constr); > > It would work then like : > > a.) parser recognises a certain tag > b.) calls the appropriate creator method to create an > object of class element > c.) sends the created object to the next layer via > the event producer Well, the above example is similar to the GroveConstructor class in the DSSSLTK. The GroveConstructor is different in that it trys to only allow sub-node objects to be created from appropriate parents. For example, the document element can only be created by passing in the SGMLDocument node. An element can only be created by passing in the parent of the element. > > An alternative to the creator methods would be to > set the objects to be created via a Hashtable of Strings. > Then the objects would be create via their "name". > > For instance an entry in the hashtable would look > like : "Element" -----> "dsssl.Element" and the > result would be the creation of an object of type > dsssl.Element for the "event" Element. I'm not certain I understand what you mean. Can you give a more detailed example? ============================================================================== R. Alexander Milowski http://www.copsol.com/ alex@c... Copernican Solutions Incorporated (612) 379 - 3608 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
|