XML API specification

[Derek Denny-Brown]

At 09:19 AM 2/27/97 -0500, Gavin 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.

yes.  Actually, it might be best to define an event interface (similar to
SP?) first, and then define a grove interface.  In terms if
test-implimentations, that means we could build an general event->grove
module which could be used on any (conforming) event generating parser

>What do people think? How much information must the parser pass 
>along?

It depends... In many cases an application could care less about resolved
entities etc (e.g. a DSSSL-O engine) It just wants the structure.  Other
times, the application wants everything.  (e.g. an editor)

If you make it a runtime switch there is performance overhead (always
checking to see if the client/application _wants_ the data you just derived)
If it is not runtime selectable then the simple case sufferes...

I would say that the event interface might have options (similar to SP) to
control which events it generates (elements, attributes, entity start/end,
dtd, etc.)  The grove interface should be able to have a similar range...
(though I am not sure that a SGML Grove can be usefully built w/o a DTD.)


On Gavin's other point... the results from the parse should allow you to
trivially build an identity transform application.  This need not include
keeping the exact format of the original source.  This means that empty
elements and elements with no content are different. etc.

-derek
-- Remember: Computers are here to make our lives easier --
ddb at criinc.com // software-engineer // www/sgml/java/perl/etc.



xml-dev: A list for W3C XML Developers
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To unsubscribe, send to majordomo at ic.ac.uk the following message;
unsubscribe xml-dev
List coordinator, Henry Rzepa (rzepa at ic.ac.uk)