W3C home > Mailing lists > Public > www-dom@w3.org > July to September 2001

Re: DOMBuilder in L3

From: Joseph Kesselman <keshlam@us.ibm.com>
Date: Fri, 6 Jul 2001 13:16:29 -0400
To: David Brownell <david-b@pacbell.net>
Cc: www-dom@w3.org
Message-ID: <OFDC2C72A1.97197101-ON85256A81.005DE33A@pok.ibm.com>

>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

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

>(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

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:08 UTC