W3C home > Mailing lists > Public > www-dom@w3.org > April to June 2000

RE: createEntity and createNotation and importing these

From: Keith W. Boone <kboone@ebt.com>
Date: Fri, 14 Apr 2000 09:27:39 -0400
To: <keshlam@us.ibm.com>
Cc: <www-dom@w3.org>
Message-ID: <001001bfa615$354ac5c0$767770c6@ebt.com>
Easy:  Yeh, it's always easy to do, but most of my costs are in maintenance,
and not in implementation, so that argument isn't terribly convincing.

Harmless:	It does increase maintenance costs for my implementation, so I
cannot really say it is harmless.  It introduces a mildly ugly extrusion in
an otherwise smooth surface.

You are going to have to do it in Level 3 Anyway:  Again, not convincing, as
I'd rather not design, develop or test dead code, and basically that is what
that code will be until Level 3 comes out.

Your last statement is an argument for putting createEntity() and
createNotation() in DOM Level 2.  Developers are going to have something
like these methods anyway just to implement importNode() in Level 2, and
they are going to have to do something like it in Level 3 anyway.

I'd prefer that, or the alternative that these nodes cannot be imported
[just as DocumentTypes cannot be imported], rather than the middle road.
Anticipating the level 3 change could be perilous.  You've made some
decisions about where the functionality is supported that you cannot change
when you add the rest of the system.

I look at the DOM Core as being a three-tiered API.  The first tier is
implementation specific details [i.e. the data structures that store the
information], the next tier are critical API methods that use the first
tier, [i.e., Element.getName()], and the next layer are convenience API
methods that can be implemented completely in terms of the second tier.

A method like importNode() looks like a 3rd tier method.  It can be 90%
implemented without any knowledge of the first tier.  What I'm complaining
about is that last 10%.  If there is a way to avoid importing Notation or
Entity nodes, or create them from the Document interface, then I've got it,
otherwise, I end up relying on implementation specific details in the first
tier.

The decision [as currently specified], has already been made that importing
a Notation or Entity is done in the Document.  However, these Nodes, don't
exist in the Document per se, but rather in the DocumentType.  Why force
that decision now, especially in light of the fact that you want to be able
to do it right in Level 3.

I think that overcoming the momentum for supporting a new feature [importing
the Notation and Entity nodes] will be easier than trying to move the import
feature for those nodes to the DocumentType [where it seems more likely that
it belongs].

	Keith

P.S.	Is this issue a dead horse yet, or is there still a chance to change
the DOM?  ;-)

-----Original Message-----
From: www-dom-request@w3.org [mailto:www-dom-request@w3.org]On Behalf Of
keshlam@us.ibm.com
Sent: Thursday, April 13, 2000 7:09 PM
To: www-dom@w3.org
Subject: RE: createEntity and createNotation and importing these


> What is see is that the Level 2 specification says [unlike what you
stated]
> that:
>    Entity nodes can be imported, however ...
>    Notation nodes can be imported, however ...

On reflection: I believe we decided on that because it's easier to support
this capability now, in anticipation of Level 3, then to change it later.
Some folks have complained loudly when an operation that used to be an
error stopped being an error, believe it or not.

> That means for me to build a conforming implementation, I would need to
> support importing entities and notations, however meaningless that
> capability is.

It may or may not be meaningless in Level 2 but I think this falls in the
category of "easy (it really is), harmless, and you're going to have to do
in in Level 3 anyway."

______________________________________
Joe Kesselman  / IBM Research
Received on Friday, 14 April 2000 09:28:29 GMT

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