W3C home > Mailing lists > Public > www-dom@w3.org > October to December 1999

Re: DOM L2 comments, various

From: Lauren Wood <lauren@sqwest.bc.ca>
Date: Thu, 25 Nov 1999 12:41:32 -0800
Message-Id: <199911252043.MAA28029@mail.sqwest.bc.ca>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 June 2012 06:13:47 GMT