General comments on parsers

[Don Park]

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


Sorry about the confusion.  I am pretty careless with names and stuff.  I
was refering to DOM level-one XML which btw is out already in draft form
(reality lag) at http://www.w3.org/TR/WD-DOM/level-one-xml-971209.html.
They also have one for HTML so I should be able to get through another
weekend with buying a book to read <g>.

So, we could probably implement the UXP based on XML DOM (gosh, I am
provising terms left and right).

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


That was the shortest wait ever, eh?

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


Long term solution.  No difference now since we have better outline of XML
DOM to work with.

>Please [ignorance] what does a registry scheme entail?


I don't know how your JUMBO allows different parsers to be used but I was
talking about registry for storing current user preferences as far as which
parser to use in your application.  It could even involve some migrating DOM
liason classes for enhancing visual representation of XML documents.
Currently, I have this vexing problem of trying to figure out how to
represent an XML document as a tree of objects where each object is
something more than a tag.  CDF has a Channel object which contains
attributes which represented as tags as well as contents of tags.  Exposing
those attributes as a tree node would be too distracting, especially since I
have a perfectly nice object inspector to show the attributes in.

>Where is the reference for W3C OM API?


See above.  Sorry again about the confucious glibbing (here I go again,
making sense only to myself).

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

Is this a different song?  Hmm, I swear I heard something else before...;-)

Don



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)