Forking the DOM (was Re: Storing Lots of Fiddly Bits)

[Matthew Sergeant (EML)]

> -----Original Message-----
> From:	Simon St.Laurent [SMTP:simonstl at simonstl.com]
> 
> Given the fairly strong comments excerpted below (and Paul's not the only
> one muttering like this), is it time to contemplate a very different API?
> The DOM's strong suit is that it provides a standard interface; however,
> that standard seems to keep running into a mismatch problem in lots of
> situations.
> 
> Is a generalized object model simply not the answer?  Do we need fifteen
> semi-standard models for use in different situations?  Could the current
> DOM be subsetted/extended to provide such functionality, or do we need to
> take a few steps back and start over, leaving the DOM for those who need
> its type of functionality but defining a new set of rules for those with
> different needs?
> 
	Don't we already _have_ different models depending on what suits the
situation best? I am coming from the perl world, not the Java world that
most people here are in, but there we have DOM, Groves, Objects, Trees, etc.
If DOM doesn't fit (which for a lot of tasks it doesn't) then there are
other options out there.

	I don't think trying to define another language independant
representation of XML is the answer here - otherwise we'll end up with X
standards for X different problems. I think you're right, but I'd rephrase
slightly: "A generalized object model isn't *always* the answer". Use what
works, and if there's nothing that works create something that does - and be
nice - let everyone else have it.

	Matt.


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/ and on CD-ROM/ISBN 981-02-3594-1
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)