|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: General comments on parsers
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@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...)
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||

Cart








