Re: DOMBuilder in L3

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

Not until supporting a "no-sugar" diet is "required", not "optional";
you seem to have ignored that (distinct) point.  (Likewise the
comments about two non-sugar feature flags -- which can be just
doc fixups.)

Since I've argued plenty for round-tripping support myself (though
normally not using DOM :) I won't argue against it.  I'll just say
I think that sugar-aware round-tripping is in the 20% app space, not
the 80% that should govern default settings.


>     Our default should
> be for maximum conformance, and therefore should be to include these nodes.

That doesn't follow.  I think it's sufficient to provide that (ignorable
whitespace) data on request.  Though whitespace is always a messy
issue, since strictly speaking only validating processors can be relied
on to tell when it's ignorable.  (Which is another doc issue that ought
to be addressed.)


> For the rest...  I don't think it's desirable for different options to
> default in different directions.... 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 "

My suggestion was to default more simply, not do so inconsistently:
"The default is to record only things that are supposed to matter to
applications, but you can save other syntax if you want."


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

That doesn't resolve the issue though.  Both "property" (in explanatory
text) and "feature" (in the API) are both used.  Perhaps switch over
completely to unadorned term "flag"?  That will involve changing the
IDL ... which now uses "feature" to refer to something other than an
optional module.  (Why not call them "optional modules"? :)

- Dave

Received on Friday, 6 July 2001 12:15:30 UTC