General comments on parsers

[Peter Murray-Rust]

At 08:18 11/12/97 -0800, Don Park wrote:
>The situation is complicated by the fact that W3C is working on and has not
>yet released its own version of Java XML Object Model.  Since it will be

Is this the same as DOM? If so, is there any timescale.

Not being part of the DOM process I am now somewhat confused. Does this
mean that there is a formal program to produce an API for XML parsers? If
so, what is the timescale? I'm sure there are some readers who are involved
;-)

I'm an impatient beast and I worry about waiting for things like this to
happen if it's going to be a long time. During that time we'll have another
5-10 Java based parsers, all with different terminology. In another
proposal I will try to  address the terminology :-)


>difficult to have all existing Java XML parsers to conform to a single
>object model, I think the best approach is for someone to write a new Java
>parser framework which provides a reasonable object model and acts as the
>Universal XML Parser (UXP?:-).

Is this a short-term or long term solution? If long term, what is the
difference/benefit between this and the OM?

>
>UXP should use some kind of simple registry scheme and a UI to allow users

Please [ignorance] what does a registry scheme entail?

>to plug in new UXP compatible parsers.  Writing UXP adapters for each of
>existing Java XML parsers should not be too hard.  Once UXP is in place, new
>parsers will start to conform.  When W3C XML API is out, all we need to do
>is write two adapters:
>
>1) UXP to W3C adapter so programs using W3C XML API can use UXP parsers
>(i.e. JavaScript).
>2) W3C to UXP adapter so programs using UXP can use any XML parsers
>providing W3C XML API.
>
>BTW, I have taken a look at Xapi-J and W3C OM API and, frankly, I am not

Where is the reference for W3C OM API? 

>satisfied with either of them.  Enumeration by index is problematic and
>callbacks are either not supported or primitive.  Not that I can offer any
>better in the near future <g>.  Call me a stuck up critic, if you will.
>
I take a very simple approach and find that the AElfred approach gives me
almost everything I want. It allows me to extract the components of the
document (start/end/content, PIs, entities) and it allows me to get almost
everything from the DTD (except the contentspec). I don't think that *I*
need anything more. I just don't want - and don't intend to write 30
adapter functions for every new parser. If everyone had
getContentSpec(String elementType) that is the level I am quite happy with :-)

	P.

>Don
>

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