Re: Level 3 Core comments

Fred L. Drake, Jr. wrote:

>Last August, I sent a note to this list with a variety of comments on
>the DOM Level 3 Core draft (the 9 April 2002 draft):
>
>http://lists.w3.org/Archives/Public/www-dom/2002JulSep/0049.html
>
>Naturally, I never received a response (which was not a surprise), but
>I've noticed that not even the most trivial typos were corrected in
>the 22 October 2002 draft.
>  
>
Many comments do get responses on this list.  The monitoring of this 
list is far from perfect, but also is quite active.  We try to respond 
in every case.  You were correct to be annoyed that typeos and more that 
you reported were not corrected in the latest draft.  We appreciate the 
reminder.

I would have responded to this earlier, but I was out of email contact 
for a few days.

>Does the WG read this list, or am I wasting my time in reviewing the
>drafts of these specifications?  I can understand that any actual
>decisions can take a long time when work is done by committee, but I
>do expect the editor can deal with typos.  I'd also expect that the
>issues raised be recorded in the little lists of issues distributed
>throughout the document.  Perhaps I misunderstand how the W3C goes
>about it's work?
>  
>
When a specification reaches last-call, this is the only forum where 
official issues may be raised, and any issue raised here about a 
specification during it's last-call period must be responded to.  It is 
the working group's clear intent to also follow issues on specs such as 
core that are not yet in last-call.  I apologize that we seem to have 
not reacted to the earlier message.

We appreciate the pointer.  I can assure you that the editors of the 
specification will look at the message if they have not already done so.

>The Python DOM binding provides a function getDOMImplementation()
>which takes the name of a DOM or feature information (it can be called
>either way), and returns a DOMImplementation object.  The feature
>information is not expressed as a simple string but as a structured
>value.
>
>This function was defined separately from the DOM drafts as our
>bootstrap mechanism (Feb 2001), but the name is identical.
>
Did this happen through coincidence?  I am not familiar enough with 
Python, but if it were Java or Javascript, a number of alternatives 
spring to mind in where to put the DOM version of the method.  It seems 
wrong to combine a DOM-specified signature with one specified by 
something else that is legacy.

Please realize that the DOM specification is still an unstable working 
draft.  For this reason, advice I give you could be easily overridden. 
 The fact that you are chasing the current signature is due to the fact 
that is is simply not stable.  Legacy code should not be considered to 
be an issue where implementation was of  an unstable working draft, 
unless the method was already there from external sources.

Having said that, the bindings have a degree of freedom in doing what is 
appropriate for their purposes and if legacy code is a fact you cannot 
ignore, then so be it.

>This function would normally be called in one of these ways:
>
>    from xml.dom import getDOMImplementation
>
>    # get anything available
>    dom = getDOMImplementation()
>
>    # get the low-memory (hah!) implementation
>    dom = getDOMImplementation("xml.dom.minidom")
>
>    # get a DOM with specific features
>    dom = getDOMImplementation(features=[("ls-load", "3.0"),
>                                         ("xml", "2.0")])
>
>I've added this to our reference implementation to come a little
>closer to the current draft:
>
>    # get a DOM with specific features
>    dom = getDOMImplementation(features="ls-load 3.0 xml 2.0")
>
>Note that passing a single string as an anonymous argument doesn't
>work, since that is interpreted as the name of a specific
>implementation.  This variant would be equivalent to the previous
>call:
>
>    dom = getDOMImplementation(None, "ls-load 3.0 xml 2.0")
>
>Another difference is perhaps more important:  If there is no suitable
>implementation, getDOMImplementation() raises a Python ImportError
>exception (this is a standard Python exception, not something created
>specifically for the DOM).
>  
>
It seems to me like you have a method that makes assumptions that may be 
wrong in the DOM-specified version of the bootstrapping mechanism.

I would suggest that you have a distinct method for dealing with the 
DOM-specified bootstrapping mechanism that does not conflict with your 
legacy method or requirements.  If this requires renaming it because of 
an unfortunate naming conflict, then so be it.  If you can put it 
statically onto a different object, perhaps that is the proper way.

It is our intent that the DOM-specified version also be able to react to 
additional feature names that may be used to identify a specific 
implementation or things not known to DOM, such as your 
"dom.xml.minidom" tag.  But the call should only succeed if it satisfies 
all requested features.

It is my belief that there are significant failures that are not be 
related to failure to import some library.  The library in question may 
well implement all of the features in question, for example, but not be 
able to supply them in the requested combination, because of the 
narrowness of a part of it's implementation.  This is one reason why the 
library supplies the source object that examines the required feature 
set in detail before supplying something.

The DOM WG does not attempt to enumerate all the possible reasons why 
the request may fail.  A Binding-specific exception may be appropriate 
in this case, as long as it is well-documented and does not interfere 
with users who may want to react to the failure.  Applications may 
immediately retry with a smaller or alternative set of acceptable 
features.  Given that this failure does not begin to describe all 
possible failures, it seems to me that it could really complicate the 
application which wants to continue to look for a matching 
implementation, becaused somethimes there would be this exception and 
sometimes there would be none, but it would still fail.

>Now for my question:  In defining the binding, is it reasonable to
>simply declare that this is close enough?  I'm very disinclined to
>provide a separate object to server as a DOMImplementationSource and
>change the argument list slightly -- having two methods with the same
>name and functionality but different signatures seems a bit
>rediculous, and I don't think we can really change the existing
>bootstrap interface since there's too much legacy code.
>
>Comments?
>  
>
The DOMImplementationSource is provided as a very flexible way for 
implementations to supply additional implementations of feature 
combinations, possibly dynamically combining them.  It permits the 
implementations great latitude in how they assemble their feature sets. 
 The pieces may all be there, but they may not be exactly assemblable in 
the combination requested.  I think you may well be compromising the 
capabilities of the API for bootstrapping someone's required feature set 
if you do not permit the implementation to judge and possibly even 
dynamically create at runtime the requested feature set.

Ray Whitmer
rayw@netscape.com

Received on Friday, 1 November 2002 10:04:12 UTC