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