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 11:41:03 -0400
To: David Brownell <david-b@pacbell.net>
Cc: www-dom@w3.org
Message-ID: <OF4F870A66.5DF0BDDE-ON85256A81.00547DDD@pok.ibm.com>

Remember, one man's "syntactic sugar" is another man's
"round-trip-ability". It's really hard to argue that either option is
clearly preferable, which is why we're supporting both. Since it's trivial
for users to explicitly override the defaults, and since it looks like half
the population will do so no matter which defaults we set, I really don't
find the syntactic-sugar argument a compelling one.

The XML Recommendation explicitly says that processors _will_ deliver
whitespace-in-element-content as part of the document's content (though it
also says that this whitespace shall be flagged as being in element
content, which past versions of the DOM didn't support). Our default should
be for maximum conformance, and therefore should be to include these nodes.
If the user explicitly requests that they be filtered out, we can do so...
but we can't do it unless they ask for it.

For the rest...  I don't think it's desirable for different options to
default in different directions, so the whitespace decision may constitute
a sufficient precident to nail down the others. It strikes me as simpler to
say "The default is to build everything, and the options allow you to
filter out the portions you aren't interested in " than to try to explain
the less-obvious concept of "filtering things in" -- especially if we are
also allowing user-written filters, as has been proposed.


Re properties versus features:  DOM convention has been that the term
"feature" replies to an optional module of the DOM API. If a flag doesn't
control something which we've defined as a feature, we shouldn't use that
term.



______________________________________
Joe Kesselman  / IBM Research
Received on Friday, 6 July 2001 11:41:37 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 June 2012 06:13:49 GMT