- 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>
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 UTC