W3C home > Mailing lists > Public > www-dom@w3.org > July to September 1999

Re: DOM L2 comments, various

From: David Brownell <david-b@pacbell.net>
Date: Mon, 27 Sep 1999 08:01:40 -0700
Message-ID: <37EF86D4.80AA8D11@pacbell.net>
To: www-dom@w3.org
A few more comments on the core, and a correction to what I said earlier.
The NamedNodeMap.setNamedItemNS method seems to be missing.

1.1.1	The description of "Document" should also say that there may only
	be a maximum of one DocumentType; it's not just true for Elements.

1.2	DOMImplementation.createDocumentType ... the more I look at it,	
	the less I like the notion that the document type be associated
	with some document "late" in the game.  Every node in the doctype
	then needs to be able to get coupled "late" to an owning document,
	rather than being so coupled from day one.  That basically means
	every type of node in the whole DOM, not just DocumentType, may
	need to work with a null ownerDocument.  Yuck.

	One patch is to have DocumentType.getEntities/getNotations be able
	to throw an appropriate exception if they're called without having
	the DocumentType bound to a document yet; that eliminates all the
	cases where nodes (perhaps many, many, many of them!) will need to
	be patched up or try to lie about their owner document.

	Of course all that still leaves open the question of when contents
	get stuffed into a DocumentType object.  Though construction seems
	to be out of scope for DOM, the spec does need to ensure there's a
	workable answer.  And I don't clearly see one now, unless it's to
	stick to the DOM L1 model without the DocumentType special cases.

1.2	Node.cloneNode ... clones are always mutable, yes?  Needs stating;
	else a conformant implementation couldn't support the process that
	was outlined with Entity nodes (mutating clones of readonly nodes).

1.2	Attr ... nit, the lack of a space after the period terminating
	the first sentence of the "Attr" description confuses javadoc.
	Looks like some tool is stripping whitespace that's a line end,
	rather than just normalizing it to other whitespace (some other
	text got merged, e.g. in that adjoined sentence).

1.2	NamedNodeMap.*ItemNS ... what should this do when being used to
	access items (notations and entities from the DTD) that aren't
	scoped with namespaces?  How about if the namespace URI is null?

	NamedNodeMap.setNamedItemNS ... no such method; why?  Everywhere
	else there are both namespace-naive and namespace-aware methods,
	but this one (very important!) case is omitted.

	NamedNodeMap.removeNamedItem ... should be able to report an
	error (NO_MODIFICATION_ALLOWED_ERR) for readonly maps, just
	like the setNamedItem method.

	NamedNodeMap.item ... negative indices should return null too

1.3	DocumentType ... please change the "publicID" and "systemID" to
	match the case ("Id" not "ID") in Notation and Entity nodes.  It's
	a gratuitous change in convention, and complicates some code
	sharing that would otherwise be natural.



David Brownell wrote:
> 
> Look    I like the report format, but I still feel like I need
>         the table of contents to have clickable links to let me
>         get to each of the documented classes.  This structure
>         (sans such TOC support) is relatively hard to navigate.

Ignore that one, sorry -- I noticed such functionality is there,
evidently I missed it before.  It does help.

- Dave
Received on Monday, 27 September 1999 11:02:48 GMT

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