Re: DOMKey in WD-DOM-Level-3-Core-20010136

[Following up to message from late March...]

Philippe Le Hegaret writes:
 > No, it just means that the user has to be careful when he moved a Node
 > from one Document to an other since the key might change. Note that it
 > doesn't prevent a DOM implementation to implement the uniquess at the
 > DOMImplementation level ...

  Now that I'm looking into DOM Level 3 a little more, I'll take a
brief moment to comment on this issue.  (I'm reading the 26-Jan-2001
draft at www.w3.org/TR/.)
  Given this rather strange idea of a DOMKey that may or may not be
maintained when moving a node between documents, shouldn't there be a
feature name that can be tested to determine if the keys are
maintained in this way?  I suspect there are a lot of properties that
should be testable in this way -- I can imagine the conformance tests
would lend themselves to be driven in this way.  (For the test suite
we're building for the Python DOM API, we do exactly this:  every
group of tests is categorized according to feature/version pairs that
can be checked with DOMImplementation.hasFeature().)

 > > (p. 16) Issue isSameNode-2:
 > >    Is this really needed if we provide a unique key?
 > > 
 > >    It seems to me isSameNode() is redundant if unique key can be
 > >    truly unique within one specific DOMImplementation.
 > 
 > following our decision on key-2, we decided to keep this one (well, at
 > least, for the moment).

  isSameNode() is also conceptually better.
  Frankly, I'd like to see some explanation of the motivation &
rationale for the DOMKey thing; it certainly seems like a strange way
to work with objects in Python (possible, but very strange).


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at acm.org>
PythonLabs at Digital Creations

Received on Wednesday, 4 April 2001 23:18:34 UTC