W3C home > Mailing lists > Public > www-dom@w3.org > October to December 1999

Re: DOM L2 comments, various

From: John G. Spragge <spragge@umich.edu>
Date: Tue, 5 Oct 1999 14:25:51 -0400
Message-ID: <002901bf0f5f$121159e0$d6b14bcf@umich.edu>
To: "Jeff Mackay" <jmackay@vtopia.com>, <www-dom@w3.org>
Jeff Mackay <jmackay@vtopia.com> wrote:

> Backward compatibility with a non-standard, but very common syntax.

Either the common syntax involved will work within the
confines of an XML structure, in which case I don't see
why you can't map it to an XML namespace by simply
parsing it, or it won't.

In the latter case, why do you want (or expect) to use
the XML DOM to process documents in a format
incompatable with XML?

> Personally, I believe that the DOM should concentrate on functionality and
> interoperability, rather than on restricting implementations.

Where does the DOM definition restrict implementations?

> The XML specs do not address backward compatibility with the billions of
> pages that currently exist (HTML, ASP, DTD, etc.).  One way to deal with
> this issue is through extending the NodeType list.  There are very likely
> other valid solutions.

Forgive me, but I don't see what you expect a node type extension
to get you. As far as I can see, the differences between HTML and
XML have nothing much to do with node types; they have to do
primarily with element closure rules. I see no reason a parser
primed with SGML closure rules could not map any derivative of
SGML into XML.

> But the real issue here is the ability of implementors to extend the DOM.

That sounds more like a political than a technical issue to me. If you
don't like the top-down process (where a comittee of experts arrives
at a proposal, then puts it out for public comment) in use here, feel
free to set up a web-based clearinghouse for actual implementations.
If software developers accept and use your facility, the DOM will
evolve into an implementation driven standard defined from "below"
by programmers who actually work on it.

But this has little to do with the technical issue of how best to
build programs to deal with existing WWW files.

> The ASP "tag" is an example where backward compatibility may be enhanced
by
> extending DOM.

If you can map ASP tags to an XML model, then I suggest you have
a parsing issue, not an issue for the model, because you can define
a namespace which maps to the ASP tags and use the ASP
compatable namespace in the existing model. If ASP will not
map to an XML namespace, then I do not see how you can
realistically expect an object model based on XML to accomodate
it.

> Other examples may include a distributed DOM or a persistent
> DOM, or a biological DOM. So again, the real question is: Are implementors
> allowed to extend the NodeType and Exception lists.

I don't see why you would have to extend the node types to
implement any of your proposed innovations.

--
J. G. Spragge ---------- standard disclaimers apply
Essays on capital punishment and network ethics at
http://www-personal.umich.edu/~spragge
Received on Tuesday, 5 October 1999 14:27:13 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 June 2012 06:13:46 GMT