Re: Comments on DOM Level 3 Load/Save

On Wed, 2002-02-20 at 15:32, Fred L. Drake, Jr. wrote:
> 1.  Issue LS-Issue-2.
> 
>     The resolution for this issue indicates that vendors should define
>     their extensions to the set of features using a vendor-specific
>     prefix string, but does not reserve any specific prefix for the
>     W3C.  This seems fairly important; I'm sure there are people who
>     expect the W3C will want to add additional features in the future.
> 
>     It wouldn't even hurt for there to be a way to "register" prefixes
>     in some way, even if it only amounts to reversing a domain name as
>     is done for Java packages.

I would have preferred personally to see URIs
(http://www.w3.org/2002/validate-if-schema) rather ad-hoc prefixes
(w3.org.validate-if-schema) but, for usability reasons (avoiding typos),
the WG decided to stick with validate-if-schema. The simple fact that
SAX is using URI and not the W3C DOM seems really inconsistent IMHO. For
events, we did pick a prefix (DOM) but now, with XML Events, we're back
to the format {http://www.w3.org/2001/xml-events},{mouseclick}, which
produce some weird naming for
{http://www.w3.org/2001/xml-events},{DOMActivate}. Anyway, having said
that, I don't see the WG changing its mind on that.

> 2.  What happened to the "namespaces" feature?
> 
>     This feature seems to have disappeared since the last version I
>     read (two drafts back, dated 7 June 2001).  I don't see this
>     mentioned in the issue notes that have been added since then.
> 
>     I'd like to understand the rationale for removing this.  I don't
>     see anything else in the spec that would allow me to avoid
>     namespace processing, and it simply isn't needed for everything.
>     I don't think the APIs should make it difficult for me to provide
>     a single DOMImplementation instance and support producing Document
>     instances parsed with and without namespaces enabled.
> 
>     Perhaps I'm missing something?  I still read namespaces as being
>     optional.

I tried to look back in our archives to find the exact reason but didn't
find it. As far as I remember, we decided that namespaces will not be
optional for the DOM Level 3 Load and Save and won't provide a way to
not have namespaces in LS. Nowadays, all XML applications provided
within the W3C (and a lot outside the W3C) do have namespaces support.
So we classified XML applications without namespaces in our design
failure category. I understand that this might be viewed as an arbitrary
choice but it is also clear in our mind that the DOM 3 LS is only *a*
solution to load a DOM tree and not *the* solution, especially when we
don't resolve at all the problems related with the XML processing model.

> 3.  Overloading of the term "feature".
> 
>     Is there a reason there are DOM features which are used to
>     determine what components are implemented, and "features" that can
>     be enabled/disabled to control specific behaviors of a component?
>     I'd really love to see these things carry different names.  The
>     later could be called "properties" to avoid confusion and term
>     overloading.

"properties" would collide with the ECMAScript properties. We used to
have "options" but it wasn't really great with our optional "options".

> 4.  Feature names for DOMImplementation.hasFeature().
> 
>     While the Abstract Schema seems to define feature names that can
>     be tested with the hasFeature() method, these are noticably absent
>     from the Load/Save specification.  I'd like to see loading and
>     saving each get a distinct feature string.
> 
>     [I see this has been brought up before and Phillipe Le Hegaret
>     said it was "fixed", but that's not a public document yet:
> 
>     http://lists.w3.org/Archives/Public/www-dom/2002JanMar/0063.html
> 
>     Though I trust Phillipe to be telling the truth, I'm leaving this
>     in for completeness, and because I don't trust non-public drafts
>     not to change.]

Thanks for the reminder. I checked our latest internal version and we
did address the issue (and rearranged a little the table of contents at
the time). We'll probably published a draft in March after addressing
the rest of your issues next week.

Philippe

Received on Friday, 22 February 2002 15:02:57 UTC