YAXPAPI (Yet Another XML Parser API)- an XDEV proposal
peter at ursus.demon.co.uk
Sat Dec 13 19:18:11 GMT 1997
At 09:59 13/12/97 -0800, Tim Bray wrote:
>At 03:19 PM 13/12/97, Peter Murray-Rust wrote:
>I agree with Peter that we should just buckle down and get on with what used
>to be known as XAPI.
>But my approach would be quite different. I think that the first step
I'm missing something :-) Your approach below seems almost identical to
what I was suggesting.
>should be the end-user's API, the kind of thing that someone using a SMIL
>or RDF processor would need. Such a person really doesn't want to wrestle
>with entities and references and PIs and marked sections; all they want
Agreed - and they wouldn't be in what I wanted as well.
>is elements and attributes and the basic doctype info; they want the
>processor to deal with entities and refs and quote marks and white space in
>markup and encodings and so on.
>This would go a long way to address the whinings of the RDF & SMIL type
>people, who thought XML just meant elements and attributes. I think that
>from their point if view, it should be, all the other stuff in the syntax
>is strictly to support authoring and management convenience.
>It should come in event-stream flavor and tree flavor.
>Minimal event stream API:
>1. Doctype, returns: root type, external subset system/public idents
I would like the elements as well. If the parser doesn't do them, we just
return null. But if it does...
>2. Element start, returns: type, element name-value pairs, whether it's empty
is "type" the elementType? This is the sort of terminological problem we
>4. End Element, returns: type
>Minimal tree API:
>1. Document, with methods: root type, system ID, public ID, root element
>2. Element, with methods: parent, children, attributeValueByName,
>3. Attribute, with methods: name, value
>4. Text (presumably hiding lazy evaluation)
>I acknowledge this is grossly insufficient for basing an editor on. You want
I don't want much for an editor. Just the attribute stuff and contentspec.
I don't want PE's, comments, marked sections and so on.
>that, use the DOM. Only a few choices have design implications:
>1. How are children returned; possibilities would be to have Element and
> Text crammed into the same class with a method for asking which is which,
> or have separate Text and Element classes, then children returns an Object
> array or a Vector, and you can find out what kind of child each member
> is using the instanceof operator. I favor the latter, Lark does this
I'm easy - **as long as we all agree**
>2. Whether it's worthwhile putting children into, as opposed to a native
> array or Vector, a special ChildList class with enumerator and indexing
> so you can hide a lazy-evaluation behind it. I favor the latter, the
which is 'the latter'? :-)
> DOM does this but Lark doesn't.
>3. Whether the processor should be required to coalesce adjacent Text
> objects. Suppose you have <a>foo <!--comment--> bar &ref; <?pi?>baz</a>,
> it's immensely less work if the processor can give this to the app
> as 4 Text chunks. I think most of the processors do this now.
I don't have a problem here...
>If I formalized and published this, it would look a lot like part of
>Lark's interface, but I bet all the other parsers could implement it.
>Should I? -Tim
I bet they could. It is very important, however, that everyone agrees on
I have never seen this as a difficult problem. I think it would take a week
to come up with a reasonable working draft. I hope that XML-DEVers will see
the value of a simple interface and not - as has happened before - keep
getting more and more complex. the three parsers we have are simple - it's
a slightly depressing situation that we haven't got an interface for them
I suggest that Tim goes ahead, but I'll also produce my interface from the
spec. After all, that will show what the *consumer* (i.e. JUMBO) would
like. As always I shall be happy to junk anything I do if it helps us make
It might also be useful for us to set ourselves a deadline.
Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic
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;
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)
More information about the Xml-dev