Goals: XML Event Interface

Peter Murray-Rust peter at ursus.demon.co.uk
Thu Dec 18 14:51:48 GMT 1997

At 07:32 18/12/97 -0500, David Megginson wrote:
>I think that the time has come to deal with a question that we have
>postponed so far: the goal of a simple XML event-driven interface.

Good thinking.  One of the really great aspects of XML was/is the 10 goals.

>Right now, there are two completely different ideas:
>1. The interface will provide standardised low-level, pre-DOM
>   functionality for parsers to implement, for programmers who do not
>   want to incur the overhead of using the DOM; perhaps a DOM tree
>   could be built using only these interfaces.

Yes. This is needed. It will be needed after the DOM is finalised. (It
might then be built on top of the DOM - I don't know). It is needed now (==
Jan 12).

>2. The interface will provide standardised high-level, post-DOM
>   functionality for parsers to implement, for programmers who do not
>   want to take the time to learn the XML concepts in the DOM; perhaps
>   the events could be generated from a DOM tree.

I understand and agree with the concept. I am not qualified to comment on
whether it is needed or is different from the API to the DOM.

>These two are actually quite incompatible: the first is an attempt to
>create a less abstract user model, while the second is an attempt to
>create a more abstract user model.  It's only a (happy) co-incidence
>that we have managed a broad agreement so far.

Yup. In my limited vision it is *possible* that (1) might be a subset of
(2), but not necessarily.
>If we decided on (1), then I would consider making the interface the
>core interface for lfred, and I would probably want to expand it
>slightly to include enough functionality to build a basic level-1 DOM
>tree, by adding some or all of the following information:
>- an event for the doctype declaration

Essential IMO

>- an isSpecified flag for attributes

Not quite clear what this is. I assume it is NOT the value of the Default
in the ATTLIST (i.e. "#IMPLIED"). BUT this concept is required in some XLL

Is it the question of the return value of a non-existent attribute. IOW
what does

<FOO BAR="baz" XYZZY="" BLORT="six      spaces"/>

return for 
String s = element.getAttval("BAR");  // answer: "baz" 
String s = element.getAttval("BLORT");// answer "six      spaces"
String s = element.getAttval("XYZZY");// answer ""
String s = element.getAttval("PLUGH");// could be "", or null
String s = element.getAttval("Y2");// could be "", or null

This is an area where I think we MUST spell out in graphic detail what is
returned. If nothing else, this is a prime reason for this API. I have got
this hopelessly muddled throughout JUMBO simply because there was no API. I
didn't want to hardcode in anything until the semantics of all this was
clear. At present JUMBO does not distinguish between a null String and "".
If this is going to be important (and I suspect it might) we need to know
NOW. It will be almost impossible to reprogram an application that gets it

Note for newcomers. If I add the declaration:


and wave it over the document, the value of BLORT changes to 

"six spaces"

This is always good for a laugh at XML parties, and you can probably make
money out of carefully placed bets.

>- ignorable whitespace (lfred should return this anyway)
>- comments (yech -- _WHY_ is that in the DOM???)
>This interface could use only JDK 1.0.2 features, since I have no
>intention of making lfred incompatible with existing browsers.



Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic
net connection
VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary

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

More information about the Xml-dev mailing list