Re: DOMBuilder in L3

>Not until supporting a "no-sugar" diet is "required", not "optional";
>you seem to have ignored that (distinct) point.

Both modes are "requried" by some applications. Both modes are available,
at the application's election. I don't think that provides particularly
clear guidance re which should be the default, either way; setting a flag
before parsing isn't exactly a major hardship or performance impact, and a
convenience routine to yield a parser configured as you need it is fairly
trivial.

For that reason, I'm not really dogmatic about which way this should go. I
do think that having the DOM default to building as complete a DOM as
possible and filtering down from there is a touch cleaner,
architecturally... but I grant that this is a matter of taste.

>"property" (in explanatory text) and "feature" (in the API) are both used.

If they're both used to refer to the same things, we should certainly fix
it. If it's a matter of "If this feature is supported by the DOM, it can be
disabled by setting that property" (where the feature is the behavior/API
and the property is the flag), we should consider whether our intent is
clear and make sure that "property", like "feature", goes into the
glossary.

>(Why not call them "optional modules"? :)

A bit late to change it now, especially given the hasFeature() method.


______________________________________
Joe Kesselman  / IBM Research

Received on Friday, 6 July 2001 13:17:08 UTC