DOM Level 3 Load/Save comments

  I'm reading from the 9-Feb-2001 version of the working draft since
that's what's available to non-members of the W3C.  These are my
comments based on trying to create an implementation (yes, I know its
a working draft and subject to change).

Issue LS-Issue-2:
    (Resolution needs to go further.)
    If short names will be used for feature names, recommending a
    prefix for third-party extensions is not sufficient.  Some prefix
    will need to be reserved for future W3C use.

2.3 Interfaces
    Feature names need to be defined for both load and save.  I'd like
    to see these be separate names, so that an implementation for
    which only one makes sense doesn't need to provide a bogus
    implementation of the other.  "load" and "save" come to mind as
    possible names -- but they need to be present in the
    specification.

DOMBuilder.entityResolver
    The description of this attribute needs to state what should
    happen if a value is not provided for this before it is needed by
    the parser.  Should a default implementation expected, and will
    there be a specification for minimal capabilities?

DOMBuilderFilter.endElement():
    It sounds like this method is responsible for removing the passed
    node from its parent if the element is to be discarded.  If that's
    the case, what is the return value used for?  I'd suggest that the
    current description be maintained, with endElement() being
    responsible for removing elements to be discarded, but change the
    return type to void.  The method should be allowed to raise
    exceptions that DOM operations can raise, and the builder should
    *not* pass those to the error handler mechanism since the document
    may be completely broken -- the exception should be propogated out
    of the parser.

DOMWriter:
    The named properties have funny names.  ;-)  The first two listed,
    normalizeCharacters and namespaceFixup, use camelCasing, but the
    third, split-cdata-sections, uses the same convention as the
    DOMBuilder property names.  (Also: decide that these are
    "properties" or "features" -- usage is inconsistent.  The same
    name should be used with both DOMBuilder and DOMWriter.)

  I'm sure I'll come up with more as I flesh out my preliminary
implementation.  This came back up to the top of my stack as I started
writing test cases for what I already have.
  I hope all the right people have time to consider my comments --
thanks for all the work!


  -Fred

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

Received on Wednesday, 4 April 2001 15:45:42 UTC