[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: Sun, 14 Dec 1997 08:31:14

At 16:07 13/12/97 -0800, Tim Bray wrote:
>At 12:03 AM 14/12/97, Peter Murray-Rust wrote:
>>I am listing the main calls from Lark and AElfred that I find useful. As
>>you can see there is a great similarity - I confess that I find the AElfred
>>ones slightly easier to understand.
>
>OK, let's get concrete.  I think that the AElfred callbacks each having
>an XMLParser argument is a good idea.  Also AElfred's names are better,
>the "Do*" prefix in Lark is silly.  So on the event-stream stuff, I'd
>go with the AElfred model modulo the following changes:

This seems eminently reasonable - if DavidM is listening I suggest we can
get this sorted very quickly.

>
>>  attribute(XmlParser, String, String, boolean) 
>
>It seems completely wrong to have an attribute event separate from
>start-element events.  To start with, it suggests that the order of 
>attributes is significant, which it is incorrect.  Secondly, since much
>element-specific processing depends on what attributes are there, it is 
>less convenient for the application programmer.  Third, if the processor
>(as it must) does defaulting, he's going to have to do some attribute
>list wrangling anyhow, so it can't really be extra work.  

I cut the documentation out to save space on the list. 
boolean isSpecified
(although this doesn't match with the documentation for the Parameters,
David...)

>
>What's the boolean?  I don't think the application author should
>to have to deal with anything but the name and value of attributes.
>
>Anyhow, I'd go with 
>
>startElement(XmlParser processor, String type, Attribute[] attributes);

So would I.

>
>and lose the attribute() method.
>
>>  data(XmlParser, String) 
>
>I feel that the 2nd argument should not be a String.  It is a recipe
>for disastrous inefficiency if the processor has to cook up a 
>java.lang.String object for every little chunk of text.  Lark uses two
>arguments, a char[] array and a character count; the app can
>make a String if it needs to.  If you find this awkward, create
>a new data type called Text so that if you need a String you
>can make it with lazy-evaluation in Text.toString(), but if you
>don't need it you don't build it.

Seems reasonable.

>
>Also, it shouldn't be named "data" - it should be named
>characterData or charData or text or some such term that can
>be mapped directly to the spec.
>
>>  resolveEntity(XmlParser, String, String, URL) 
>
>I don't think entities have any place in the first cut of this 
>interface.  The processor exists to make these problems go away.

Lark has entities:
public boolean doSystemTextEntity(Entity e, String name, String extID)
and two others...

>
>Generalities: 
>Lark has a thing where if any callback returns 'true', the
>parser drops out of its loop... which is awfully useful and easy
>I think.  Lark will also re-enter, but this need not be a requirement.
>
>Also, for application programmers, especially dealing with smallish
>objects, a tree interface is very natural.  I've written both
>event-stream and tree apps using Lark, and the trees are a lot
>easier to use for anything even moderately complex.  So the API 
>should have Element, Attribute, and Text classes. 

I won't quarrel with this. I would be very happy for a tree interface,
because JUMBO is based on trees. However I didn't want to subclass Lark's
trees if we decided on a different one, because unlike an event stream,
that could take a major rewrite of JUMBO. IFF we can standardise now, I'll
be very happy.

>
>And it shouldn't (sorry Peter) be called YAXPAPI - how about SAX, Simple

Of course it shouldn't - I would second the use of Simple somewhere in it.

>API for XML?  Maybe SAX-J for the Java bindings. -Tim
>
Sounds great. let's make sure we get 100% of the way this time.

	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: Re: YAXPAPI (Yet Another XML Parser API)- an XDEV proposal
• Next by Date: XML-DEV (was Re: YAXPAPI)
• 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