DOMBuilder in L3

I recently had occasion to look at the DOMBuilder interface in
the current "Level 3" WD:

http://www.w3.org/TR/2001/WD-DOM-Level-3-ASLS-20010607/load-save.html#LS-Interfaces-DOMBuilder

I'd like to suggest that four of the default feature settings are
inappropriate.  These should all default to 'false', not to 'true'

    - create-entity-ref-nodes
    - white-space-in-element-content
    - cdata-nodes
    - comments

The rationale is that all those node types are "syntactic sugar"
and not intended to convey logically significant information to
applications.  This means that creating them by default is
inappropriate (it encourages _use_ of insignificant "sugar") as
well as undesirable (it wastes memory).  Applications that, for
legacy reasons, want such sugar can ask that it be reported;
other applications shouldn't need to bother.

It may be worth considering "comments" separately, since
they unfortunately show up (legacy processes?) in the XPath
data model.  I think it's appropriate to discourage their use
everywhere, but reasonable people might expect a DOM
to handle "full" XPath without needing to enable comments.


Additionally, setting these flasgs to 'false' should be required, not
optional; only the "comments" flag requires that.  (That's implied
by changing to defaults of 'false'.)  Having "false" be optional
forces applications to manually filter out such sugar, and makes
this feature flag much less useful than it ought to be.


I'd also suggest revisiting the "charset-overrides-xml-encoding"
flag.  Minimally, document that changing this default (to 'false')
makes applications violate the XML standard.  It'd be good to
at least describe why this would be desirable.  (For example,
stating that it may be necessary to work around misconfigured
web servers.)

Related, the "validate-if-cm" flag has a similar issue.  Setting it
to "true" violates the XML specification of a validating parser;
that should be identified as a reason to keep this flag cleared.


Also, there seems to be some confusion in the text about
whether to call these "properties" or "features".  Please
refer to them using only one term, preferably "features"
or, for more suggestive language, "feature flags" (which
captures the notion that these are boolean values).

- Dave

Received on Friday, 6 July 2001 11:13:53 UTC