Comments on DOM Level 3 Load/Save

I've finally gotten back to the DOM Level 3 Load/Save draft, and have
started playing with a Python implementation again.  I have a few
comments/questions.

These are based on the 14 Jan 2002 draft.

1.  Issue LS-Issue-2.

    The resolution for this issue indicates that vendors should define
    their extensions to the set of features using a vendor-specific
    prefix string, but does not reserve any specific prefix for the
    W3C.  This seems fairly important; I'm sure there are people who
    expect the W3C will want to add additional features in the future.

    It wouldn't even hurt for there to be a way to "register" prefixes
    in some way, even if it only amounts to reversing a domain name as
    is done for Java packages.

2.  What happened to the "namespaces" feature?

    This feature seems to have disappeared since the last version I
    read (two drafts back, dated 7 June 2001).  I don't see this
    mentioned in the issue notes that have been added since then.

    I'd like to understand the rationale for removing this.  I don't
    see anything else in the spec that would allow me to avoid
    namespace processing, and it simply isn't needed for everything.
    I don't think the APIs should make it difficult for me to provide
    a single DOMImplementation instance and support producing Document
    instances parsed with and without namespaces enabled.

    Perhaps I'm missing something?  I still read namespaces as being
    optional.

3.  Overloading of the term "feature".

    Is there a reason there are DOM features which are used to
    determine what components are implemented, and "features" that can
    be enabled/disabled to control specific behaviors of a component?
    I'd really love to see these things carry different names.  The
    later could be called "properties" to avoid confusion and term
    overloading.

4.  Feature names for DOMImplementation.hasFeature().

    While the Abstract Schema seems to define feature names that can
    be tested with the hasFeature() method, these are noticably absent
    from the Load/Save specification.  I'd like to see loading and
    saving each get a distinct feature string.

    [I see this has been brought up before and Phillipe Le Hegaret
    said it was "fixed", but that's not a public document yet:

    http://lists.w3.org/Archives/Public/www-dom/2002JanMar/0063.html

    Though I trust Phillipe to be telling the truth, I'm leaving this
    in for completeness, and because I don't trust non-public drafts
    not to change.]

5.  DOMBuilder.entityResolver.

    The description should describe what support a builder is expected
    to provide if the resolver is not specified.  When a new builder
    is created, should a default resolver be exposed via this
    attribute, to allow client code to "wrap" a basic resolver, or
    should the default value be null?  (This kind of information would
    be helpful for many attributes in the DOM spec.)

6.  DOMBuilder.errorHandler.

    When a new builder is created, should a error handler be exposed
    via this attribute, to allow client code to "wrap" a handler, or
    should the default value be null?

7.  Terminating parsing from a DOMBuilderFilter.

    The description of the DOMBuilderFilter states that parsing can be
    terminated early using a filter, but doesn't give a specific
    recommendation or mechanism regarding how to do this.  Should this
    be binding-specific, or is there a particular DOM exception which
    should be raised?

8.  DOMBuilderFilter.whatToShow.

    The description of this attribute states that attribute nodes will
    never be passed to the filter, and the description of the filter
    interface also states that the document element will not be passed
    to the filter.  What about the Document, DocumentType, Notation,
    and Entity nodes?

9.  DocumentLS.saveXML().

    Why would the return value ever be null?

10. Typos.

    No, I didn't spell-check the thing, but I did notice a few.

    "validate-against-dtd" description: "Prefere"
    DOMBuilder.errorHandler description: "DOMDcoumentBuilder"
    DOMBuilder.parseWithContext() description: "epcified"


  -Fred

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

Received on Wednesday, 20 February 2002 15:34:03 UTC