The repeated wording "an application data" is rather odd; 'data' is of course plural.

the new method of prepending a '+' to the feature name seems rather clumsy. If a Level 2 feature is updated to a Level 3 feature which can be non-castable, an application that wants the Level 2 feature and doesn't care about casting would have to call hasFeature twice to find out whether the feature can be supplied, once with "+"..."3.0" and once with "2.0".

it seems to be impossible to rename a node and end up with a non-namespace (Level 1) node. For orthogonality, shouldn't there be renameNode and renameNodeNS?

by my reading of the definition of "logically adjacent text nodes", fooNode's wholeText should also give "barfoo". Is this a mistake? If not, why is fooNode adjacent to barNode but not vice versa? If wholeText is only supposed to look forwards, the spec should say so.

still seems a bit vague. How exactly does a fatal error differ from an error? Can an error handler be called for arbitrary DOM exceptions, or just the few circumstances defined here? Are parse errors in Load/Save going to cause DOMErrors? What should DOMErrorHandlers do with unrecognised errors? Are the "wf-..." errors warnings?

"Discard all Text nodes that contain whitespaces in element content" implies that Text nodes in element content with *any* whitespace characters in their data should be removed, rather than Text nodes composed *only* of whitespace. I'm pretty sure this is not what was meant.

"The DOMString attribute of the Text node..." - surely "The data attribute...".

Is it possible to find out if the type of an Element or Attribute is derived from some specific type in the Schema?

What I would like to see is something like the Xerces XSTypeDefinition.derivedFrom method in the TypeInfo interface.

Consider the following addition for the NameList interface:

The implementation of DOMImplementationRegistry shown in Appendix G.1 makes use of a Java System Property to record a list of names of classes that implement DOMImplementationSource. A user of the registry may naturally infer that sources are checked in the order specified by this property (and the order by which additional sources are added to the registry using the addSource() method). However, this may or may not be the case since the implementation of DOMImplementationRegistry shown here makes use of a Hashtable which does not guarantee any specific enumeration order.

I would suggest doing one of the following:

The draft states:

An attribute specifying, as part of the XML declaration, the version number of this document. If there is no declaration, the value is "1.0".

HTML (served as text/html) documents do not have XML declarations, and in this case it seems to me this propery should return null, not "1.0". Am I correct in making this assumption? Or should this really be returning "1.0" in that case as well?

Document interface, "xmlStandalone" and "xmlVersion" attributes: both descriptions say that there is a NOT_SUPPORTED_ERR if this document *does* support the "XML" feature. Shouldn't that be does *not* support?

typically using uppercase for element names and lowercase for attribute names

The "typical" behavior in the L3 Core is contrary to DOM L2 HTML which specifies that both attribute names and element names should be uppercase which currently only Opera and Konqueror implement. The best solution I see is to issue an errata to L2 HTML specifying that attribute should be lowercase. Otherwise, this sentence should be expanded to not appear to be recommending behavior contrary to L2 HTML.

There has been a bug on www-dom-ts to ask for clarification if hasFeature("Core", "1.0") should return true since the L1 recommendation only had "XML" and "HTML" features. This sentence should reflect the resolution of that issue. At the end of the first paragraph of 1.4, "1.0" is omitted which could be interpreted as supporting the "Core didn't exist in L1" position.

ordered collection of parallel pairs of name and namespace values

should read

ordered collection of qualified names

getName() does not define whether the return value is a local name or might contain a namespace prefix. I'd would assume that local name would be preferrable. Changing the name to getLocalName() would be clearer and consistent with XPath.

Throwing an exception on out of range indexes is not consistent with DOMStringList and other lists. I can understand the motivation since getNamespaceURI() could be null before the end of the list, however you could distinguish between a null namespace and end of the list since getName would be null at the end of the list.

I dislike the form of this interface for a couple of reasons: it requires that each implementation source to parse the features list which could have been done once for all implementation sources and it enables the implementation source to return inconsistent first implementation sources. I'd suggest something like

I believe that eliminates any use of DOMImplementationList so that interface could be eliminated.

Just a minor further nitpick on L3 Core: the DOMError ErrorSeverity definition group starts at 0; for consistency with the rest of the spec it should probably be 1.

I complained originally that what exactly DOMError severity meant was not adequately defined in the WD. Having now implemented it this way, I'd suggest something like the following:

Going back to DOM 2, this attribute's description has started "The namespace URI of this node, or null if it is unspecified". This seems quite clear, and in programming languages like Java, I expect a null value in that language to be returned.

However, there are implementations that do not use what I would consider to be a null. For example, Oracle's XML parser's Node.getNamespaceURI() returns an empty (zero-length) string, and Microsoft's .NET framework (the NamespaceURI property of the System.Xml.XmlNode class) likewise returns an empty string.

I would like to see DOM 3 Core clarify or amend the statement "The namespace URI of this node, or null if it is unspecified". If implementations returning empty strings are to be considered out-of-spec, please specify this explicitly. If returning a zero-length string is an acceptible implementation according to the standard, please state this. If this issue is clarified elsewhere in the DOM 3 spec, please refer to that place from the description of Node.namespaceURI.

Not adequately explained. Is this the encoding at the time of parsing? Do subsequent saves change the value? initialEncoding might be better.

Using an abbreviation is unusual.

Should it be possible (or required) for an implementation to raise an exception if a new value is set that is not a valid URI.

Can an implementation raise an exception if it does not recognize the encoding on setting? How is this affected by saves? Does this affect saves (which would be in the L/S spec)? Maybe it is cleaner just to allow the encoding to be specified on the save request.

What occurs when this attribute is set to true and the document does not satisify the requirements for standalone="yes".

The difference between adoptNode and importNode is not immediately obvious.

The fact that this does not throw an INVALID_CHARACTER_ERR when a 1.0 document adopts a node containing names not legal in 1.0 is clarified but really bizarre. Why is this different from importNode()?

or null if the operation fails, such as when the source node comes from a different implementation.

This seems to be a opening for an implementation to always return null. The expected failure scenarios should be enumerated as exceptions.

What is the behavior when attempting to change the attribute name to the name of an attribute that already exists on the element.

The two apis getDOMImplementation and getDOMImplementations could cause confusion. I would prefer if a more distinct name is used. e.g getDOMImplementationList (Similarly, I would prefer if getFeatures is changed to getFeatureList).

To be consistent with the other attributes, probably it should be added that "This attribute is false when unspecified".

This is said to be from the XML declaration, but is boolean whereas the XML declaration can specify 3 values: "yes", "no" and not specified. Either the datatype should be changed or (my preference) it should be specified that this is true when the XML declaration says "yes", false otherwise.

Appendix C.1.1 says that this comes from the [standalone] property, but does not address the case where the property has no value.

It is not clear whether the text should be returned when it contains "any" whitespace or when it has "all" whitespace as its element content.

How do the definitions differ from XPath's axes? Why CONTAINED_BY instead of ANCESTOR and CONTAINS instead of DESCENDANT? Could there not be bits to indicate parent, child, attribute, sibling and self? Is there a compelling reason to fabricate an order for attributes of the same element or for nodes in different documents?

I would think that Node.compareDocumentPosition would be very prone to usage errors. Most scripting languages would not provide symbolic constants and it would be relatively easy to misuse bit-wise operators.

It would seem a whole lot simplier and more usable to provide boolean methods that correspond to the XPath Axes,

Plus the existing isSame(Node node) for the self axis. descendant-or-self and ancestor-or-self could be handled by or'ing isSame and the appropriate other axis test.

Adding a method to determine if the nodes are in the same document might also be helpful.

If you are only interested if the particular pair are, for example, parent and child, it should be more efficient to only check that instead of figuring out how they are related.

It would be useful if there was some statement that if an DOMImplementation.hasFeature(feature, version) returns true that Node.getFeature(feature, version) could not return null or something else that would allow you to always use getFeature() and not have to try both getFeature() and casting.

This would be more appropriate as an read-only attribute. The description is insufficient since it doesn't explicitly explain under what conditions the implementation is able and required to determine that the content model only contains elements.

Attr.isId() is a declared as a method, though it would be more appropriate as an attribute. If made a read-write attribute, then Element.setIdAttribute(), Element.setIdAttributeNS() and Element.setAttributeNode() could be eliminated since you could do the equivalent using Element.getAttributeNode[NS]().isId = true | false.

The description of DOMErrorHandler.handleError mentions that the error parameter may be reused across multiple calls. That would suggest the need for a clone method on DOMError in case a handler wishes to hold on the error.

I would prefer enhancing Events to enable UserData maintenance, though that may require defining events types for cloning and importing and adding a DOMStringList userDataKeys attribute to Node.

If not, does there need to be an NODE_ADOPTED operation type.

NODE_DELETED is problematic. However, mimicing DOMNodeRemovedFromDocument would be well defined for garbage-collected platforms.

Having attributes that allow you to readily determine if the type is complex vs simple or named vs anonymous would seem to be helpful. Such as:

XML Schema Datatypes has equivalents for the DTD attribute types which could be used instead of null and attribute type property. The current definition would not provide an easy way to distinguish between:

and

An anonymous type could be nested many levels down in the content model, a containingElements NameList attribute could be used to enumerate the element names. For the schema:

The TypeInfo associated with the world element in:

would have

The description of the boolean return value appears to describe three different behaviors by explaining how a value of true differs from the default behavior and how a value of false differs from the default behavior. But there is no way of specifying that you want the implementation to do the default behavior.

This should be split up into a distinct byteOffset and characterOffset. An implementation could return values for both, a value for one and -1 for the other or -1 for both. However, the user doesn't have to somehow know the nature of the source to interpret the values.

There should be two attributes, one for byte offset and the other for character offset (or alternatively another attribute that says whether "offset" is byte or character), since the application may not be able to determine if the source was bytes or characters.

White space is two words (see all prose and productions in XML 1.0 except one typo in 1998 and the Infoset since WD-xml-infoset-20010202). I don't know why it wound up being one word in [element content whitespace]. Do you? isWhitespaceInElementContent could (should?) be isWhiteSpaceInElementContent and whitespace-in-element-content could be white-space-in-element-content. If Last Call is too late to change those, perhaps at least the prose could match XML and the Infoset to say "white space" (rather than "whitespaces").

the description doesn't say that this is supposed to be the qualified name of the node. Nor do the descriptions of Element.tagName and Attr.name. One has to determine that from the description of Node.prefix!

the spec should clearly specify that when retrieving the value of an attribute that contains a reference to an entity for which no definition is available, the processor will treat this entity reference as an empty reference (see the reply to C15 in Core I18N response). Same comment for Element.getAttribute() and Element.getAttributeNS().

The 4th paragraph starts "XML does not mandate that a non-validating XML processor read and process entity declarations made in the external subset or declared in external parameter entities." The last occurrence of "external" is superfluous and somewhat misleading, since non-validating processors are not obligated to read even *internal* parameter entities. This latter point is pretty obscure and under-documented in the XML spec, but see the last sentence in XML 1.0, as well as published erratum E8 at XML 1.0 Erratum E8.

There seems to be useless redundancy in the last "if". Paraphrasing: "If there's a declaration, change it, else create one or change an existing one". Either drop the "if" and keep the "else" part or keep the "if" and drop "or changing" from the "else" part.

The first sentence (after the initial Note) is really hard to parse. Comments in the algorithms say things like "if the prefix/namespace pair is within scope...", using this wording would be clearer. It's not an element that's within scope, it's really the prefix/namespaceURI pair. Some rewording/tightening needed.

In C 1.1.1, Document.actualEncoding should be set to [character encoding scheme], which is "The name of the character encoding scheme in which the document entity is expressed." in the infoset spec, not necessarily the value of the encoding pseudo-att of the XML declaration. Document.xmlEncoding probably should not be set.

In appendix C.1.2, [character encoding scheme] should be set from Document.actualEncoding.

Document.xmlVersion should be "The [version] property or 1.0 if the latter has no value."

Same, mutatis mutandis, for xmlStandalone (false if no value).

[notations] should be "Document.doctype.notations", in order to point to the correct DocumentType object.

the statement "Element nodes with no namespace URI (Node.namespaceURI equals to null) cannot be represented using the Infoset." is counterfactual. The infoset supports these, provided names do not contain colons.

Node.previousSibling and Node.nextSibling should be set to null.

it should be clarified that CDATASection nodes cannot occur from an infoset mapping, since the infoset doesn't contain CDATA section boundaries.

This is very much improved since the previous version, but unfortunately still not totally clear. Since the DOM stores documents in UTF-16 exclusively, these attributes must necessarily refer to the encoding of a serialized document that is parsed to create the DOM tree; since xmlEncoding is not read-only, it can also be set programmatically, but that shouldn't change its semantics. Semantics is precisely where some dark spots remain. actualEncoding is pretty clearly defined as the actual encoding of the parsed document, supposedly gleaned from the parser. xmlEncoding is then said to be taken from the XML declaration, but Appendix C.1.1 says that xmlEncoding is supposed to come from the infoset's [character encoding scheme] property. The latter is defined as "The name of the character encoding scheme in which the document entity is expressed", matching the semantics of actualEncoding, not those of an encoding label read from the XML declaration. So the meaning of xmlEncoding remains pretty murky.

One wonders why there are actually 2 attributes, since there is only one encoding of interest: that of the document that was parsed to create the DOM tree. If the intent was to enable DOM users to control encoding during later serialization, this is defeated by the order of priorities specified in DOMSerializer.write(): actualEncoding precedes xmlEncoding. The former being read-only, the user has no control.

Should specify, like createAttribute() and others, that an INVALID_CHARACTER_ERR exception can be thrown, depending on the "xmlVersion" attribute.

This should also perform character normalization, perhaps conditional to the config of the containing Document. This method's business in life is to concatenate Text nodes; concatenation is one of the well-known cases that actually produces character denormalization. It would be silly to have a method called normalize() which actually denormalizes, so any denormalizations caused by concatenation should be repaired as part of the method's normal functioning. Backward compatibility can probably be addressed by making the repairs conditional on xmlVersion or the config of the containing document or both.

Also, it should be specified that this method is sensitive to the value of the "cdata-sections" config parameter.

Are the various methods supposed to maintain character normalization? Under the control of the config of the containing Document? Of "strictErrorChecking"?

The config parameters "check-character-normalization" and "normalize-characters" appear to be pertinent, but neither their descriptions nor the descriptions of the CharacterData.* methods say that they have any effect for these methods.

This should default to false. CDATA sections are mere syntactic sugar with no structural role (hint: they do not exist in the infoset), they do not deserve to be preserved by default.

it is not clear *when* this setting has any effect (i.e. what methods of what interfaces it affects). Since Charmodel says that text SHOULD be checked, the default for this should be true, the user having the chance to set it to false after careful consideration of the consequences (see definition of SHOULD in RFC2119).

The reference to Unicode 3.0 should be updated to Unicode 4.0, ISBN 0-321-18578-1.

We consider this section overly vague. At least two points should be improved:

Would an iterator make sense in the DOMConfiguration? That would allow the properties to be discovered dynamically, instead of hardwiring strings like "canonical-form" in applications. Or perhaps a getNextProperty()?

Some methods may raise several types of exceptions. It can be situations where more then one exceptional conditions are met at the same time. Is it described anywhere how to determine exceptions' precedence?

For example if I try to call insertBefore method on a readonly node with newChild being the node created from a different document, which exception should be raised: NO_MODIFICATION_ALLOWED_ERR or WRONG_DOCUMENT_ERR?

It appears that the DOM Core spec doesn't specify what should happen if the prefix attribute is set on a node of a type other than ELEMENT_NODE or ATTRIBUTE_NODE. It does state that the prefix is always null, but should setting it be a no-op or throw an exception?

Consider the interface CharacterData from DOM Level 1. The method deleteData has an unsigned long parameter named count. The technical report says that if the specified count is negative the exception INDEX_SIZE_ERR should be raised. But since count is an unsigned long, it makes no sense to say an exception should be raised if the count is negative; an unsigned long can't be negative.

In practice, this creates a problem for language binding implementors. For example, the W3C DOM test suite has an ECMAScript test that attempts to pass a negative number to deleteData, and expects INDEX_SIZE_ERR. But conceptually, it's the ECMAScript DOM language binding that is going to encounter the need to convert the negative number to an unsigned long, and I think it may be unreasonable to expect the language binding to know that it should raise a DOMException INDEX_SIZE_ERR in this case, since the process of converting argument types shouldn't be required to know details of individual DOM methods.

I was unable to find any standard that defines what should happen to values of inappropriate types that are passed through a language binding. I expect that's outside the scope of the DOM technical report.

There's definitely a problem here, but I'm not sure what can be done to the DOM technical report to fix this. Perhaps the idea of using unsigned long as the type in the CharacterData interface is the problem; it's certainly inconsistent to talk about a negative count if a count is an unsigned long.

This issue exists for the substringData, insertData, deleteData, and replaceData methods of the interface CharacterData, and the splitText method of the interface Text.