Re: DOM L2 comments, various

David Brownell wrote:
> 
>         * The system and public IDs are really for the "document
>           type's external subset", not for the "document type", as
>           it's now written.

Fine.

> 
>         * I can't see how I'd write a chunk of code that'll know it
>           can use Level 2 features ... e.g. it's portable and needs
>           to work with both L1 and L2.

I don't understand, the idea is that you'd write something like:

if (DOMImplementation.hasFeature("XML", "2.0")) {
  printOutElementWithNS(el);
} else {
  printOutElement(el);
}

>           I'd like to see a "DOM" feature (for DOMImplementation) be
>           defined, which would report on which level is supported.

Like what? Something like this:

DOMString getFeature(DOMString feature)

that would return the version? I can see some use for it but it doesn't
seem so necessary to me.


>         * It's confusing to have feature definitions scattered all
>           over the spec.
> 
>           I'd like to see them collected in one table at one place, so
>           their overall scope is more readily understood.

I'll see what I can do on that front.

>         * I still don't see why there's no solution for getting access
>           to a system default DOM implementation, at least for Java.

I don't think there is any good reason apart from the lack of time to
discuss it.

>           I'm posting an implementation in a followup post.  I'd like
>           to see something like this in the org.w3c.dom Java package.

Thank you.

> 1.1.7   Namespaces ... it may be useful to note that the DOM has
>         adopted an 'early binding' model of namespace URIs to
>         elements.  With early binding, the URIs are permanently
>         bound to elements as they get created.

Ok, I've tried to make this clearer.

> 1.2     DOMException ... ambiguous re whether the other numeric
>         codes are reserved to W3C or not.  They should be.
> 
>         Similar comment for "Node" ... nobody except W3C should
>         be defining new numeric codes for "nodeType".

I added wording to make this clear.

> 1.2     Document ... refers to "invalid" characters.  "Illegal"
>         would be more correct (with reference under DOMException
>         to XML, HTML, and related specs for what that means).  Of
>         course the INVALID_CHARACTER_ERR name is grandfathered...

This comes from DOM Level 1...

> 1.2     Document.importNode ... I'm rather uncomfortable with that
>         name "import" since that implies the same object is in use
>         (e.g. if I import something from Canada).  "copy" is the
>         appropriate word, and is even used in the documentation
>         more than once.  "import" suggests the wrong thing.

I'll see what the WG wants to do about that one.

Thank you very much for your careful review Dave!
-- 
Arnaud  Le Hors,  W3C  -  http://www.w3.org/People/Arnaud

Received on Monday, 4 October 1999 11:49:11 UTC