Re: DOM L2 comments, various

> > I'm more sympathetic to defining new exception
> codes outside the range
> > of the types defined by W3C.
> 
> A similar argument applies to node types; one may as
> well use the same
> convention for both.  It's always better to have an
> explicit extension
> mechanism in the spec, so that each application
> doesn't go off in its own
> completely incompatible direction.
> 

I second that motion. The DOM chose a dual mechanism
for representing types--interfaces and "codes". 
Nothing prevents me from defining a "supernode"
interface that extends (or is derived from) Node.
Nothing should prevent me from defining a
corresponding SUPERNODE node type "code".

How about a real-world example that has nothing to do
with a DTD?  Lets say I write a parser that processes
Active Server Pages.  The syntax used to mark
server-side scripts is <% //insert your script here
%>.  The script marker nodes are custom node types. 
They can be interpreted, executed,
color-syntax-edited, etc. 

Some may argue that these things are really processing
instructions. But they aren't. Others may say they are
really just comments. But they aren't. They are script
markers. 

Still others might say that since they violate XML
syntax rules I can't create a new node type.  Let me
worry about that--I'll take the responsibility for
making sure that my application/parser/processor are
smart enough to handle them. I know that they probably
won't be added to the DOM in the near future, so let
me define a ScriptMarker interface, and a ScriptMarker
NODETYPE constant.  And I'd prefer it if you would
tell me which range of values to use so that 
I don't get in trouble when the DOM adds that
newfangled supermetaschemanode in the next release.

It's a pretty simple request...



=====

__________________________________________________
Do You Yahoo!?
Bid and sell for free at http://auctions.yahoo.com

Received on Monday, 4 October 1999 15:46:45 UTC