- From: Lauren Wood <lauren@sqwest.bc.ca>
- Date: Thu, 25 Nov 1999 12:41:32 -0800
- To: www-dom@w3.org
On 26 Sep 99, at 14:25, David Brownell wrote:
> 1.2 General re compatibility ... I don't see how I can write
> a chunk of code that'll know to act differently if it's
> using DOM Level 2 or DOM Level 1.
>
> SUGGESTION: have a DOMImplementation 'feature". "DOM"
> would have values "1.0" (for DOM L1) or "2.0" (L2).
hasFeature has a version number ("2.0" for Level 2). Since most of
the modules are optional, just asking whether an implementation
supports Level 2 is equivalent to asking whether it supports Level 2
Core, and not much use if, for example, you want to know if
traversal is implemented.
> 1.2 DOMException ... ambiguous re whether the other numeric
> codes are reserved to W3C or not. They should be.
They are, and it's now in the spec.
> Similar comment for "Node" ... nobody except W3C should
> be defining new numeric codes for "nodeType".
Agreed. Also in the spec now.
> 1.2 DomImplementation ... createDocumentType() seems to have
> no accomodation for an internal subset. I'd suggest at
> least correcting the text; it's not the "document type
> system identifier" (or public ID), but the "external
> subset system identifier" (or public identifier).
Fixed the text, and added an internal subset as a string.
> Also, having the "feature" identifiers scattered throughout
> the document is suboptimal. At least list the features
> from each chapter up at the front of the chapter, in a
> table to visually highlight them.
We added a table to the introduction to list these. Thanks for the
suggestion.
> 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...
Corrext. Fixed,
> 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.
We discussed this again, and "copyNode" didn't seem any better,
so we're sticking with "importNode".
> 1.3 DocumentType ... as above on DomImplementation, the text
> should say the IDs are for the "document type's external
> subset",
True.
> 7 Traversal ... I'm still not a fan of this stuff, but at
> least it's optional. (Seems like it should integrate with
> the view mechanism in some places, but doesn't -- oops.)
???
> App C Java Binding ... I ** REALLY ** think it'd be useful to
> define a standard way to get access to a DOM implementation,
> so that only parser connectivity really needs to be left
> to nonstandard APIs.
We started work on this; quickly found that the simple solution
didn't cover all the pitfalls so it will take more work to get right.
Lauren
Received on Thursday, 25 November 1999 15:46:42 UTC