[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: YAXPAPI (Yet Another XML Parser API)- an XDEV proposal

• From: Peter Murray-Rust <peter@u...>
• To: xml-dev@i...
• Date: Sat, 13 Dec 1997 19:36:41

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
yup
yup
yup

>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
have.


>3. Text
>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,
allAttributes
>3. Attribute, with methods: name, value
>4. Text (presumably hiding lazy evaluation)

Sounds OK.

>
>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
the terminology.


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
to use.

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
progress :-)

It might also be useful for us to set ourselves a deadline.  

	P.


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

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

• References:
  • Re: YAXPAPI (Yet Another XML Parser API)- an XDEV proposal
    • From: Tim Bray <tbray@t...>

• Prev by Date: OFE
• Next by Date: Re: OFE
• Previous by thread: Re: YAXPAPI (Yet Another XML Parser API)- an XDEV proposal
• Next by thread: Re: YAXPAPI (Yet Another XML Parser API)- an XDEV proposal
• Index(es):
  • Date
  • Thread