Re: Level 3 Core comments

Ray Whitmer writes:
 > 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.

I'm glad to hear this list is monitored; for those of us not
affiliated with W3C member organizations, this is the only way to get
comments in.

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

That's not a problem; I really don't expect an instant reponse!  I'm
not actually concerned about getting any personal response; what does
concern me was that information and comments I provided did not seem
to have any effect at all -- I think I brought up some real issues
that at least warrented open issues in a subsequent version of the
draft.  Had those been acknowledge *somehow*, I probably wouldn't have
checked whether the typos got fixed.  ;)

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

Thanks for the updates on the process, and I'll look forward to the
next draft.

I described the Python bindings:
 > 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.

Ray asked:
 > Did this happen through coincidence?

Yes; we did not know anything about the eventual DOM 3 interface at
that time (20 months ago).  I'd be surprised if the DOM WG did, though
I've been surprised before.

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

In general, I agree.  The catch is that two distinct groups (the W3C
DOM WG and the Python XML-SIG) are working in the same area.

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

I definately understand the draft status -- one of the reasons for
starting implementaiton work is to determine if there's anything about
the draft that will cause substantial difficulties for implementors,
or which will cause unexpected performance behaviors for
applications.  I'd say that makes this the right time to comment on
the draft, so that we (users) end up with something that makes sense
and works as expected.

I'm not concerned with legacy code that relied on interfaces defined
in old drafts -- our documentation states clearly that anything based
on drafts is subject to change until the final recommendations are
implemented.  I *am* concerned about legacy code that relied on
something the XML-SIG defined that was not covered by the DOM of the
time.

For now, we've decided to leave the implementation of that particular
feature alone until we see either of

- changes in the DOM Level 3 draft, or

- further comments from our own user community.

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

There do seem to be some differences.

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

I suspect that would be the easiest to maintain.  If the XML-SIG finds
a good name/place for it, that's all we really want at this point.  I
think I can deal with the differences in assumption in a sligtly
different way and make it work for both interfaces without introducing
the additional complexity for implementations that don't need it.

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

I understand that; I agree that our use of ImportError is potentially
misleading, but consider this a minor detail.  Since any Python code
can raise this exception, it can do this whenever appropriate.  There
is precedent in interpreting ImportError as "feature not available" in
Python.

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

Yes, that's where our existing API falls down.  We haven't had any
requests for that ability, though, so it's not clear how real of a
limitation that is.  I'm fairly certain it won't be difficult to
accomodate, so I think we're actually in pretty good shape.

Thanks for your time, and for paying attention!


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at acm.org>
PythonLabs at Zope Corporation

Received on Friday, 1 November 2002 16:48:45 UTC