DOM Level 3 Core Issues List

clover-1: an application data [link to this issue]

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

Editorial concerning

DOMUserData

Transition history

raised on 11 Jun 2003 by Andrew Clover

agreed on 9 Jul 2003

agreed.

Acknowledgment cycle

announced by group on 24 Jul 2002

agreement by reviewer on 9 Oct 2003

clover-2: DOM features and plus (+) sign [link to this issue]

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".

Clarification concerning

DOM Features

Transition history

raised on 11 Jun 2003 by Andrew Clover

declined on 9 Jul 2003

The application would need to care anyway since, depending on the result, it will have to access the object that implements the interface using getFeature or by simple cast.

Acknowledgment cycle

announced by group on 24 Jul 2002

agreement by reviewer on 9 Oct 2003

clover-3: renameNode and non-namespace nodes [link to this issue]

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?

Proposal concerning

Document.renameNode

Transition history

raised on 11 Jun 2003 by Andrew Clover

declined on 16 Jul 2003

We discussed that and didn't find enough interest in having a renameNode/renameNodeNS solution, so unless people start to express an interest in having it, we won't do it. By the way, createDocument is another exception to that orthogonality...

Acknowledgment cycle

announced by group on 24 Jul 2002

agreement by reviewer on 9 Oct 2003

clover-4: logically adjacent and wholeText [link to this issue]

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.

Clarification concerning

• Text.wholeText
• logically-adjacent text nodes

Transition history

raised on 11 Jun 2003 by Andrew Clover

agreed on 16 Jul 2003

" that may be visited sequentially in document order "

should read (in logically adjacent definition)

that can be visited sequentially in document order or in reversed document order

Example has been fixed accordingly.

Acknowledgment cycle

announced by group on 24 Jul 2002

agreement by reviewer on 9 Oct 2003

clover-5: error types [link to this issue]

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?

Clarification concerning

• parameter "well-formed"
• DOMError

Transition history

raised on 11 Jun 2003 by Andrew Clover

agreed on 23 Jul 2003

A fatal error stops the processing, unlike an error.

No. DOMExceptions are and stay exceptions. The relatedException is meant to platform dependent ones, not DOMException. An example would be a SecurityException or IOException when using DOMParser.

We certainly don't intent to define the required behaviors of DOMErrorHandler for recognized or unrecognized errors. The unrecognized error must be of one of the 3 severity levels but that's all. No changes were done to the specification.

Acknowledgment cycle

announced by group on 24 Jul 2002

agreement by reviewer on 9 Oct 2003

clover-6: whitespace-in-element-content [link to this issue]

"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.

Clarification concerning

parameter "whitespace-in-element-content"

Transition history

raised on 11 Jun 2003 by Andrew Clover

declined on 23 Jul 2003

The definition of whitespaces in element content is quite clear in the draft, especially since the following sentence indicates that Text.isWhitespaceInElementContent() should be used. We added an extra link to the infoset property as well.

Acknowledgment cycle

announced by group on 24 Jul 2002

agreement by reviewer on 9 Oct 2003

clover-7: Text.data [link to this issue]

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

Editorial concerning

CDATASection

Transition history

raised on 11 Jun 2003 by Andrew Clover

agreed on 23 Jul 2003

correct.

Acknowledgment cycle

announced by group on 24 Jul 2002

agreement by reviewer on 9 Oct 2003

stenius-1: derived types [link to this issue]

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.

Request concerning

TypeInfo

Transition history

raised on 12 Jun 2003 by Petteri Stenius

agreed on 14 Aug 2003

isDerivedFrom has been added to TypeInfo.

Acknowledgment cycle

announced by group on 29 Aug 2002

agreement by reviewer on 9 Oct 2003

Action history

arnold-1: NameList: contains and containsNS [link to this issue]

Consider the following addition for the NameList interface:

 boolean contains(DOMString name);
 boolean containsNS(DOMString namespaceURI, DOMString localName);

Request concerning

NameList

Transition history

raised on 4 Jun 2003 by Curt Arnold

accepted on 18 Jun 2003

Background, proposals, threads, notes

While the Group rejected the proposal to remove ElementEditVAL.isElementDefined and ElementEditVAL.isElementDefinedNS (cf the appropriate resolution of this DOM Level 3 Validation issue), it has been decided to consider the addition of contains and containsNS.

agreed on 23 Jul 2003

contains and containsNS have been added.

Acknowledgment cycle

announced by group on 24 Jul 2002

agreement by reviewer on 27 Oct 2003

adams-1: DOMImplementationRegistry behavior [link to this issue]

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:

1. abstract the definition of DOMImplementationRegistry in Appendix G.1 to specify it in terms of an interface rather than a class; furthermore, define its behavior more clearly in terms of order of evaluation in the case that two or more DOMImplementationSource instances implement the same features;
2. rewrite the implementation in G.1 to use an ordered container type, such as a List;
3. specify that the behavior is undefined as to which DOMImplementationSource will be returned when more than one supports the same features.

Proposal concerning

• org/w3c/dom/bootstrap/DOMImplementationRegistry.java
• DOMImplementationSource

Transition history

raised on 19 Jun 2003 by Glenn A. Adams

agreed on 14 Aug 2003

Fixed. we picked option 2.

Acknowledgment cycle

announced by group on 15 Aug 2003

agreement by reviewer on 15 Aug 2003

aillon-1: Document.xmlVersion [link to this issue]

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?

Clarification concerning

Document.xmlVersion

Discussion history

5 Aug 2003

Transition history

raised on 10 Jul 2003 by Christopher Aillon

agreed on 30 Jul 2003

Document.xmlVersion should be null if not dealing with XML.

Acknowledgment cycle

Not started

raised again on 6 Aug 2003 by François Yergeau, on behalf of XML Core

agreed on 6 Aug 2003

The description should say that the exception is raised is the XML feature is *not* supported.

Acknowledgment cycle

announced by group on 6 Aug 2002

arnold-2: attribute name case [link to this issue]

" 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.

Error concerning

• Case of attribute names in HTML documents for L1 Core tests
• String comparisons in the DOM

Transition history

raised on 8 Jul 2003 by Curt Arnold

agreed on 18 Feb 2004

The sentences:

"For instance, element and attribute names are exposed as all uppercase (for consistency) when used on an HTML document, regardless of the character case used in the markup. Since XHTML is based on XML, in XHTML everything is case sensitive, and element and attribute names must be lowercase in the markup. "

should read

"For instance, element names are exposed as all uppercase (for consistency) when used on an HTML document, regardless of the character case used in the markup. The names of attributes defined in HTML 4.01 are also exposed as all lowercase, regardless of the character case used in the markup, but for other attributes (i.e. ones that are not defined by HTML 4.01), the character casing is implementation dependent. Since XHTML is based on XML, in XHTML everything is case sensitive, and element and attribute names must be lowercase in the markup."

Acknowledgment cycle

Not started

Action history

arnold-3: hasFeature and Core 1.0 [link to this issue]

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.

Clarification concerning

DOM Features

Transition history

raised on 8 Jul 2003 by Curt Arnold

agreed on 16 Jul 2003

The feature "Core" wasn't defined in "1.0". The text in DOM Level 2 Core is indeed misleading and should not make any claims regarding hasFeature("Core", "1.0"). The DOM Level 3 Core was changed as follows:

" For example, this specification defines the features "Core" and "XML", and thus for the version "3.0". Versions "1.0" and "2.0" can also be used for features defined in the corresponding DOM Levels. "

Acknowledgment cycle

announced by group on 16 Jul 2003

agreement by reviewer on 27 Oct 2003

arnold-4: ordered collection [link to this issue]

" ordered collection of parallel pairs of name and namespace values "

should read

ordered collection of qualified names

Editorial concerning

NameList

Transition history

raised on 16 Jul 2003 by Curt Arnold

agreed on 6 Aug 2003

We change NameList: "ordered collection of parallel pairs of name and namespace values (which could be null values)"

Acknowledgment cycle

announced by group on 3 Oct 2003

agreement by reviewer on 27 Oct 2003

Action history

arnold-5: getName vs getLocalName [link to this issue]

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.

Proposal concerning

NameList

Transition history

raised on 16 Jul 2003 by Curt Arnold

agreed on 6 Aug 2003

Correct. This depends on its usage. NameList is meant to be a generic interface and used in different ways depending on the context. The DOM Level 3 Validation draft has been clarified to make that context clear.

Acknowledgment cycle

announced by group on 3 Oct 2003

Action history

arnold-6: exceptions in NameList [link to this issue]

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.

Proposal concerning

NameList

Discussion history

30 Jul 2003

Transition history

raised on 16 Jul 2003 by Curt Arnold

agreed on 6 Aug 2003

The index is declared as unsigned. The exceptions have been removed. getName() can return null even before the end of the list, if wildcards are in use for example. (as indicated in ElementEditVal) The application can only rely on NameList.length in order to know the end of the list.

Acknowledgment cycle

announced by group on 6 Aug 2003

agreement by reviewer on 27 Oct 2003

arnold-7: DOMImplementationSource [link to this issue]

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

interface DOMImplementationSource {
  DOMImplementation getDOMImplementation(DOMStringList features, 
                                         DOMStringList versions,
                                         unsigned int index);
}

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

Proposal concerning

DOMImplementationSource

Discussion history

11 Aug 2003, 12 Aug 2003

Transition history

raised on 16 Jul 2003 by Curt Arnold

declined on 14 Aug 2003

We clarified the description of getDOMimplementation as follows:

" This method returns the first item of the list returned by getDOMImplementationList. "

Acknowledgment cycle

announced by group on 28 Aug 2003

objection from reviewer on 28 Aug 2003

getDOMImplementationList() seemed to be required of an implementation source but never used by a DOMImplementationRegistry.

objection accepted by group on 10 Sep 2003

This question was reconsidered.

agreed on 10 Sep 2003

DOMImplementationRegistry.getDOMImplementationList was broken and has been fixed.

Acknowledgment cycle

announced by group on 10 Sep 2003

agreement by reviewer on 27 Oct 2003

Action history

clover-8: DOMError severity [link to this issue]

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:

• A SEVERITY_WARNING error will not cause processing to stop unless a DOMErrorHandler returns false. If there is no DOMErrorHandler set up, processing will always continue.
• A SEVERITY_ERROR error will cause processing to stop unless a a DOMErrorHandler returns true. If there is no DOMErrorHandler set up, processing will always stop.
• A SEVERITY_FATAL_ERROR will always cause processing to stop. Return value from handleError is ignored.

Proposal concerning

DOMError

Discussion history

30 Jul 2003

Transition history

raised on 21 Jul 2003 by Andrew Clover

agreed on 14 Aug 2003

We clarified the description of the constants and changed their values.

Acknowledgment cycle

announced by group on 28 Aug 2003

agreement by reviewer on 9 Oct 2003

nichol-1: Node.namespaceURI [link to this issue]

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.

Proposal concerning

Node.namespaceURI

Discussion history

25 Jul 2003, 25 Jul 2003

Transition history

raised on 21 Jul 2003 by Scott Nichol

agreed on 14 Aug 2003

We updated the section on XML namespaces and added alink to that section from Node.namespaceURI.

Acknowledgment cycle

announced by group on 28 Aug 2003

arnold-8: actual encoding? [link to this issue]

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

Clarification concerning

• Document.actualEncoding
• Entity.actualEncoding

Transition history

raised on 30 Jul 2003 by Curt Arnold

declined on 14 Aug 2003

the description is accurate. It is the encoding used while loading the document. The value is read-only and cannot be changed, including the LS module. write* operations in LS don't never modify the document.

Acknowledgment cycle

announced by group on 28 Aug 2003

objection from reviewer on 29 Aug 2003

I assume that you meant "adequate" in the first sentence in the previous paragraph and I would disagree since I could not find anything is the spec like the second sentence in the previous paragraph. Is there some other recommendation that already uses the term "actual encoding" in the manner?

If that is your intention, I think that "initialEncoding" is clearer.

objection accepted by group on 10 Sep 2003

This question was reconsidered.

agreed on 10 Sep 2003

In order to clearly express that it represents the encoding used during the load of the Document, the attribute was renamed "inputEncoding". This matches the idea of an input, introduced by the DOMInput interface in the LS module.

Acknowledgment cycle

announced by group on 10 Sep 2003

agreement by reviewer on 27 Oct 2003

arnold-9: config or configuration? [link to this issue]

Using an abbreviation is unusual.

Editorial concerning

Document.config

Transition history

raised on 30 Jul 2003 by Curt Arnold

declined on 14 Aug 2003

No changes.

Acknowledgment cycle

announced by group on 28 Aug 2003

agreement by reviewer on 29 Aug 2003

arnold-10: documentURI and valid URIs [link to this issue]

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.

Proposal concerning

Document.documentURI

Transition history

raised on 30 Jul 2003 by Curt Arnold

declined on 14 Aug 2003

We didn't want to go into the issue of URI/IRI checking, so no exception or error if you set to an invalid one. I clarified that no lexical checking was done when setting documentURI. baseURI will return null if an absolute URI cannot be determined. Note that we don't check the xml:base attributes either.

Acknowledgment cycle

announced by group on 28 Aug 2003

agreement by reviewer on 29 Aug 2003

arnold-11: recognized XML encoding [link to this issue]

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.

Clarification concerning

• Document.xmlEncoding
• Entity.xmlEncoding

Transition history

raised on 30 Jul 2003 by Curt Arnold

declined on 14 Aug 2003

xmlEncoding has been changed to read-only, in order to simplify the computation of the encoding used at save time (i.e. only DOMOutput.encoding could be changed). Save defines an "unsupported-encoding" error if the encoding is not supported.

Acknowledgment cycle

announced by group on 28 Aug 2003

agreement by reviewer on 30 Aug 2003

agreement agreement by reviewer on 23 Sep 2003

arnold-12: Requirements of standalone [link to this issue]

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

Proposal concerning

Document.xmlStandalone

Transition history

raised on 30 Jul 2003 by Curt Arnold

agreed on 14 Aug 2003

normalizeDocument and the DOMSerializer will catch it, as defined by the XML specification: this is a validity constraint. I added for that effect in the description of xmlStandalone.

Acknowledgment cycle

announced by group on 28 Aug 2003

proposal from reviewer on 30 Aug 2003

There should be something in L/S that allows you to specify that you want to document serialized with standalone="yes" which would either place everything in the internal subset or expand entity references and explicitly serialize default attribute values.

declined on 8 Oct 2003

It would be dangerous to start doing "magic" based on the value of thestandalone attribute. XML Parsers are required to check the value ofstandalone when validating. It is therefore logic to do the same in theDOM and make the check dependent on the validate and validate-if-schemaparameters. No change is needed in the specifications since this errortype is already controlled by XML.

Acknowledgment cycle

announced by group on 10 Oct 2003

agreement by reviewer on 27 Oct 2003

arnold-13: adoptNode and importNode [link to this issue]

The difference between adoptNode and importNode is not immediately obvious.

Editorial concerning

• Document.importNode
• Document.adoptNode

Transition history

raised on 30 Jul 2003 by Curt Arnold

declined on 14 Aug 2003

We think that the current description is clear enough.

Acknowledgment cycle

announced by group on 28 Aug 2003

proposal from reviewer on 29 Aug 2003

It would be good if the first sentences in each description were parallel. For example, adopt could say:

"Attempts to adopt a node from another document to this document. [...] If supported, the source node is removed from the original document and altered changing the ownerDocument of the node and any descendants,,,"

proposal incorporated by group on 29 Aug 2003

The new text says:

"Attempts to adopt a node from another document to this document. If supported, it changes the ownerDocument of the source node, its children, as well as the attached attribute nodes if there are any. If the source node has a parent it is first removed from the child list of its parent. This effectively allows moving a subtree from one document to another (unlike importNode() which create a copy of the source node instead of moving it). When it fails, applications should use Document.importNode() instead."

importNode-1: adoptNode and importNode [link to this issue]

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()?

Editorial concerning

• Document.importNode
• Document.adoptNode

Transition history

raised on 8 Aug 2003 by François Yergeau, on behalf of Internationalization WG

declined on 14 Aug 2003

importNode will invoke createElement -> so exception

adoptNode will never invoke createElement -> so no exception

Acknowledgment cycle

announced by group on 28 Aug 2003

agreement by reviewer on 28 Aug 2003

arnold-14: adoptNode return value [link to this issue]

"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.

Proposal concerning

Document.adoptNode

Transition history

raised on 30 Jul 2003 by Curt Arnold

declined on 14 Aug 2003

Correct, it is indeed an opening for an implementation to refuse to adopt a node from one document to an other. Several failure scenarios can happen, predictable or implementation dependent ones, so any list would be incomplete.

Acknowledgment cycle

announced by group on 28 Aug 2003

agreement by reviewer on 27 Oct 2003

arnold-15: Attributes and renameNode [link to this issue]

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

Clarification concerning

Document.renamedNode

Transition history

raised on 30 Jul 2003 by Curt Arnold

declined on 14 Aug 2003

The current description says:

" When the node being renamed is an Attr that is attached to an Element, the node is first removed from the Element attributes map. Then, once renamed, either by modifying the existing node or creating a new one as described above, it is put back. "

i.e. it will replace the old attribute node, since it is equivalent to the removal of the Attr node, then set it back using setAttributeNode.

Acknowledgment cycle

announced by group on 28 Aug 2003

agreement by reviewer on 29 Aug 2003

manian-1: getDOMImplementation(s) [link to this issue]

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).

Proposal concerning

DOMImplementationSource

Transition history

raised on 30 Jul 2003 by Anjana Manian

agreed on 14 Aug 2003

done.

Acknowledgment cycle

announced by group on 28 Aug 2003

manian-2: unspecified standalone [link to this issue]

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.

Proposal concerning

Document.xmlStandalone

Transition history

raised on 30 Jul 2003 by Anjana Manian

raised again on 6 Aug 2003 by François Yergeau, on behalf of XML Core

agreed on 6 Aug 2003

added "This is false when unspecified."

Acknowledgment cycle

announced by group on 6 Aug 2002

manian-3: whitespaces [link to this issue]

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.

Proposal concerning

Text.isWhitespaceInElementContent

Transition history

raised on 30 Jul 2003 by Anjana Manian

agreed on 14 Aug 2003

This method maps to the Infoset property "element-content-whitespace".

Acknowledgment cycle

announced by group on 28 Aug 2002

arnold-16: Position comparison [link to this issue]

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,

boolean isChild(Node node);
boolean isDescendant(Node node);
boolean isParent(Node node);
boolean isAncestor(Node node);
boolean isFollowingSibling(Node node); // always false for attribute
boolean isPrecedingSibling(Node node);  // always false for attributes
boolean isSibling(Node node);
boolean isFollowing(Node node);
boolean isPreceding(Node node);
boolean isAttribute(Node node);

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.

Clarification concerning

Node.compareDocumentPosition

Transition history

raised on 31 Jul 2003 by Curt Arnold

declined on 14 Aug 2003

The addition of several methods in order to achieve the current functionality of compareDocumentPosition doesn't really encourage to change the current proposal, especially since it is easier to add a new constant than a new method if future extensions. So we still prefer the current proposal in the specification...

Acknowledgment cycle

announced by group on 28 Aug 2002

arnold-17: getFeature and hasFeature [link to this issue]

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.

Proposal concerning

Node.getFeature

Transition history

raised on 31 Jul 2003 by Curt Arnold

declined on 14 Aug 2003

You are comparing DOMImplementation.hasFeature and Node.getFeature (instead of Node.isSupported and Node.getFeature?). if Node.isSupported("+Events", "3.0"), then it is guarantee that getFeature will work in that node with the same feature/version.

Acknowledgment cycle

announced by group on 28 Aug 2002

agreement by reviewer on 27 Oct 2003

arnold-18a: isWhitespaceInElementContent() or isWhitespaceInElementContent ? [link to this issue]

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.

Proposal concerning

Text.isWhitespaceInElementContent

Discussion history

5 Aug 2003, 5 Aug 2003

Transition history

raised on 1 Aug 2003 by Curt Arnold

agreed on 14 Aug 2003

done. For Java, if an attribute starts with "is" that is followed by an upper case character, then the getter keeps the name as-is. The setter replaces "is" with "set". Only exception is HTMLInputElement.isMap as suggested. IsId and isWhitespaceInElementContent (now renamed to isElementContentWhitespace) are back to be attributes again.

We renamed the method to make it clear that it reflects the Infoset property "elenment-content-whitespace". Also added a link to the Infoset in the description.

Acknowledgment cycle

announced by group on 28 Aug 2002

arnold-18: isId() or isId ? [link to this issue]

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.

Proposal concerning

Attr.isId

Transition history

raised on 1 Aug 2003 by Curt Arnold

declined on 14 Aug 2003

done, but as a read-only attribute, since that would require the implementation to create an attribute node for the invocation of isId. The purpose of the setIdAttribute* is to provide the ability for the element node to be returned by getElementById, which does not require creating an Attr node.

Acknowledgment cycle

announced by group on 28 Aug 2002

arnold-19: DOMError.clone() [link to this issue]

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.

Proposal concerning

DOMError

Transition history

raised on 1 Aug 2003 by Curt Arnold

declined on 14 Aug 2003

Not common enough as a use case to be addressed by the API. This can be done easily by the application anyway.

Acknowledgment cycle

announced by group on 28 Aug 2002

agreement by reviewer on 27 Oct 2003

arnold-20: User data and event handling [link to this issue]

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.

Proposal concerning

UserDataHandler

Transition history

raised on 1 Aug 2003 by Curt Arnold

declined on 14 Aug 2003

it would also require to support events in order to handle the user data appropriately. NODE_ADOPTED has been added instead.

Acknowledgment cycle

announced by group on 28 Aug 2002

agreement by reviewer on 27 Oct 2003

arnold-21: anonymous types [link to this issue]

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:

readonly attribute boolean isSimple;
readonly attribute boolean isAnonymous;
      (may be redundant with typeName == null)

Proposal concerning

TypeInfo

Transition history

raised on 1 Aug 2003 by Curt Arnold

declined on 14 Aug 2003

This request goes into the debate of how much of the PSVI API should be included on this interface. We judge this one to be a real PSVI addition than a type generic one.

Acknowledgment cycle

announced by group on 28 Aug 2002

agreement by reviewer on 27 Oct 2003

arnold-22: XML Schema and DTD types [link to this issue]

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:

<!ATTLIST foo name CDATA #IMPLIED>

and

<!--  contrived, no namespace schema   -->
<xsd:schema>
<xsd:simpleType name="CDATA"/>
...
<xsd:attribute name="name" type="CDATA"/>

Proposal concerning

TypeInfo

Transition history

raised on 1 Aug 2003 by Curt Arnold

declined on 14 Aug 2003

An application can always know the schema apply to the document by checking the schema-type parameter of the configuration object, so there is a way to distinguish them.

Acknowledgment cycle

announced by group on 28 Aug 2002

arnold-23: nested and anonymous types [link to this issue]

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:

<xsd:schema targetNamespace="http://www.example.com/typeinfo">
<xsd:element name="hello">
    <xsd:complexType>
         <xsd:choice>
             <xsd:element name="world">
                   <xsd:simpleType>...</xsd:simpleType>
             </xsd:element>

The TypeInfo associated with the world element in:

<hello xmlns="http://www.example.com/typeinfo">
    <world/>
</hello>

would have

typeName == null,
typeNamespace == null,
isSimple == true,
containingElements.getNamespace(0) == "http://www.example.com/typeinfo",
containingElements.getName(0) == "hello"
containingElements.getNamespace(1) == null
      (if elementFormDefault = false) or "http://www..."
containingElements.getName(1) == world

Proposal concerning

TypeInfo

Transition history

raised on 1 Aug 2003 by Curt Arnold

declined on 14 Aug 2003

Why not looking at the ancestors of the node where the TypeInfo is attached?

typeName and typeNamespace cannot be both null if there is a declaration. In your case, it will exposed the the namespace and local name of the corresponding anonymous type name, with anonymous type name being an implementation-defined, globally unique qualified name provided by the processor for every anonymous type declared in a schema.

Acknowledgment cycle

announced by group on 28 Aug 2002

arnold-24: handleErrors [link to this issue]

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.

Clarification concerning

DOMErrorHandler.handleError

Transition history

raised on 1 Aug 2003 by Curt Arnold

agreed on 14 Aug 2003

It has been clarified that the "error-handler" parameter of the DOMConfiguration object of the document may contain a default error handler if not set by the application.

Acknowledgment cycle

announced by group on 28 Aug 2002

agreement by reviewer on 27 Oct 2003

arnold-25: byte and character offsets [link to this issue]

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.

Proposal concerning

DOMLocator.offset

Discussion history

15 May 2003

Transition history

raised on 1 Aug 2003 by Curt Arnold

raised again on 8 Aug 2003 by François Yergeau, on behalf of Internationalization WG

agreed on 14 Aug 2003

offset has been splitted in byteOffset and utf16Offset (since the DOM deals with utf-16 units, and not characters).

Acknowledgment cycle

announced by group on 28 Aug 2002

agreement by reviewer on 23 Sep 2003

agreement agreement by reviewer on 27 Oct 2003

lesch-1: isWhitespaceInElementContent or isWhiteSpaceInElementContent ? [link to this issue]

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").

Editorial concerning

• Text.isWhitespaceInElementContent()
• parameter "whitespace-in-element-content"

Discussion history

1 Aug 2003, 3 Aug 2003, 4 Aug 2003, 5 Aug 2003, 5 Aug 2003, 5 Aug 2003

Transition history

raised on 1 Aug 2003 by Susan Lesch

agreed on 14 Aug 2003

The name of the method isWhitespaceInElementContent has been changed to isElementContentWhitespace to better reflect that it refers to the Infoset property "element-content-whitespace". Same kind of change has been applied to the "whitespace-in-element-content" parameter. Since it is too late to rename the Infoset property, and our method and parameter are mapped to it, we don't plan to rename them, whatever the outcome of the whitespace vs white space is. Regarding the prose itself, we will happily change to whatever becomes the recommendation, and thus at any stage.

Acknowledgment cycle

announced by group on 28 Aug 2002

yergeau-1: nodeName? [link to this issue]

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!

Clarification concerning

Node.nodeName

Transition history

raised on 6 Aug 2003 by François Yergeau, on behalf of XML Core

agreed on 14 Aug 2003

clarified.

Acknowledgment cycle

announced by group on 28 Aug 2002

yergeau-2: Attribute values and entity references [link to this issue]

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().

Clarification concerning

Attr.value

Discussion history

12 Jun 2003

Transition history

raised on 6 Aug 2003 by François Yergeau, on behalf of XML Core

agreed on 14 Aug 2003

clarified.

Acknowledgment cycle

announced by group on 28 Aug 2002

yergeau-3: Entity declarations [link to this issue]

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.

Clarification concerning

Entity

Discussion history

12 Jun 2003

Transition history

raised on 6 Aug 2003 by François Yergeau, on behalf of XML Core

agreed on 14 Aug 2003

The superfluous occurrence of external has been removed.

Acknowledgment cycle

announced by group on 28 Aug 2002

yergeau-4: redundant if? [link to this issue]

void Element.normalizeNamespaces()
{
      ...

      // Fixup element's namespace
      //
      if ( Element's namespaceURI != null )
      {
        ...
      }
      else
      {
        // Element has no namespace URI:
        if ( Element's localName is null )
        {
          ...
        }
        else
        {
          // Element has no namespace URI
          // Element has no pseudo-prefix
          if ( default Namespace in scope is "no namespace" )
          {
            ==> do nothing, we're fine as we stand
          }
          else
          {
            if ( there's a conflicting local default namespace declaration
                 already present )
            {
              ==> change its value to use this empty namespace.

            }
            else
            {
              ==> Set the default namespace to "no namespace" by creating or
              changing a local declaration attribute: xmlns="".

		}

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.

Editorial concerning

Appendix B.1

Transition history

raised on 6 Aug 2003 by François Yergeau, on behalf of XML Core

agreed on 14 Aug 2003

fixed.

Acknowledgment cycle

announced by group on 28 Aug 2002

yergeau-5: Namespace algorithm [link to this issue]

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.

Editorial concerning

Appendix B.1.1

Transition history

raised on 6 Aug 2003 by François Yergeau, on behalf of XML Core

agreed on 14 Aug 2003

The section was reworded a bit.

Acknowledgment cycle

announced by group on 3 Oct 2002

Action history

yergeau-6: actualEncoding vs xmlEncoding [link to this issue]

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.

Error concerning

• Infoset mapping: Infoset to Document node
• Infoset mapping: Document node to Infoset

Transition history

raised on 6 Aug 2003 by François Yergeau, on behalf of XML Core

agreed on 6 Aug 2003

Fixed.

Acknowledgment cycle

announced by group on 6 Aug 2002

yergeau-7: xmlVersion mapping [link to this issue]

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).

Editorial concerning

Infoset mapping: Infoset to Document node

Transition history

raised on 6 Aug 2003 by François Yergeau, on behalf of XMLCore

agreed on 6 Aug 2003

Fixed (for both xmlVersion and xmlStandalone).

Acknowledgment cycle

announced by group on 6 Aug 2002

yergeau-8: notations mapping [link to this issue]

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

Editorial concerning

Infoset mapping: Document node to Infoset

Transition history

raised on 6 Aug 2003 by François Yergeau, on behalf of XML Core

agreed on 6 Aug 2003

Fixed.

Acknowledgment cycle

announced by group on 6 Aug 2002

yergeau-9: no namespace and Infoset [link to this issue]

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.

Error concerning

Infoset mapping: Element node to Infoset

Transition history

raised on 6 Aug 2003 by François Yergeau, on behalf of XML Core

agreed on 14 Aug 2003

fixed. (sentence removed)

Acknowledgment cycle

announced by group on 28 Aug 2002

yergeau-10: previous and next sibling mapping [link to this issue]

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

Error concerning

Infoset mapping: Infoset to Attr node

Transition history

raised on 6 Aug 2003 by François Yergeau, on behalf of XML Core

agreed on 6 Aug 2003

Fixed. This applies to Node.parentNode as well.

Acknowledgment cycle

announced by group on 6 Aug 2002

yergeau-11: CDATA sections and Infoset [link to this issue]

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

Editorial concerning

Infoset mapping: Infoset to Text node

Transition history

raised on 6 Aug 2003 by François Yergeau, on behalf of XML Core

agreed on 6 Aug 2003

Added.

Acknowledgment cycle

announced by group on 6 Aug 2002

yergeau-12: actualEncoding and xmlEncoding [link to this issue]

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.

Clarification concerning

• Document.actualEncoding
• Document.xmlEncoding

Transition history

raised on 8 Aug 2003 by François Yergeau, on behalf of Internationalization WG

agreed on 14 Aug 2003

xmlEncoding is now read-only, and only represents what was found in the XML declaration, if any. actualEncoding was the encoding used to load the document, again if any. For the Save module, it should be clarified that the XML declaration, if generated, will get whatever encoding was used for the serialization, and not actualEncoding or xmlEncoding necessarily.

Acknowledgment cycle

announced by group on 29 Aug 2002

agreement by reviewer on 23 Sep 2003

yergeau-13: renameNode and invalid characters [link to this issue]

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

Error concerning

Document.renameNode

Transition history

raised on 8 Aug 2003 by François Yergeau, on behalf of Internationalization WG

agreed on 14 Aug 2003

fixed

Acknowledgment cycle

announced by group on 29 Aug 2002

agreement by reviewer on 23 Sep 2003

yergeau-14: normalize() and character normalization [link to this issue]

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.

Proposal concerning

Node.normalize()

Transition history

raised on 8 Aug 2003 by François Yergeau, on behalf of Internationalization WG

declined on 14 Aug 2003

normalize() is a DOM Level 1 method. The name is unfortunate since it collides character normalization but we cannot change its semantics or rename it. This explains the introduction of normalizeDocument(), instead of reusing normalize() on Document nodes. An other example of discrepancy with names is our namespaceURI and the [namespace name] Infoset property.

Acknowledgment cycle

announced by group on 29 Aug 2002

objection from reviewer on 23 Sep 2003

This doesn't seem to address the comment. Backward compatibility is certainly an issue, but not necessarily a show-stopper: there are numerous instances of "Modified in DOM Level 3" in the spec. We did offer some ideas for addressing compatibility, they may be dead-on-arrival but we would like to understand why.

objection accepted by group on 1 Oct 2003

This question was reconsidered.

agreed on 1 Oct 2003

The issue was reconsidered and we agreed with the recommendation.

Acknowledgment cycle

announced by group on 2 Oct 2003

yergeau-15: CharacterData methods and character normalization [link to this issue]

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.

Clarification concerning

CharacterData

Transition history

raised on 8 Aug 2003 by François Yergeau, on behalf of Internationalization WG

agreed on 17 Sep 2003

The description of the DOMString interface has been changed to reflect the fact that only normalizeDocument has the control over the character normalization.

Acknowledgment cycle

announced by group on 18 Sep 2002

proposal from reviewer on 23 Sep 2003

some rewording would be appreciated.

proposal accepted by group on 1 Oct 2003

This question was reconsidered.

agreed on 1 Oct 2003

The paragraph was rewording to include the change on Node.normalize() as well.

Acknowledgment cycle

announced by group on 2 Oct 2003

Action history

yergeau-16: "cdata-sections" default must be false [link to this issue]

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.

Proposal concerning

parameter "cdata-sections"

Discussion history

16 Apr 2003, 18 Apr 2003, 12 Jun 2003

Transition history

raised on 8 Aug 2003 by François Yergeau, on behalf of Internationalization WG

declined on 14 Aug 2003

The parse methods of the LS module don't load CDATA sections by default (the "infoset" parameter is true by default, this implies that cdata-sections default is false for the parse methods). So unless an application adds CDATASection nodes during manipulations, the "cdata-sections" parameter won't change anything in the tree. And if the application do add CDATASection nodes in the tree, or the parse operation was requested to preserve the cdata sections, then they should be preserved by default since the application explicitly asked to get them.

Acknowledgment cycle

announced by group on 29 Aug 2002

agreement by reviewer on 23 Sep 2003

yergeau-17: check character normalization? [link to this issue]

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).

Clarification concerning

parameter "check-character-normalization"

Transition history

raised on 8 Aug 2003 by François Yergeau, on behalf of Internationalization WG

declined on 14 Aug 2003

The parameter check-character-normalization is optional so the default cannot be true. Applications can certainly check if the parameter is activated, or can be activated, using the methods defined on the DOMConfiguration object.

Acknowledgment cycle

announced by group on 29 Aug 2002

objection from reviewer on 23 Sep 2003

The optional character of check-character-normalization is the first wrong (the other being that "true" is not the default). As argued in our comment, a DOM user cannot do the right thing (check normalization unless careful consideration of the consequences...) if the normalization checking functionality is absent. The DOM is missing functionality essential for things as ssimple and basic as string matching. We object to that.

objection maintained by group on 2 Oct 2003

For performance reasons, we believe the character normalization cannot be true by default. Also, no one in the WG committed to implement this feature.

yergeau-18: Unicode 4.0 [link to this issue]

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

Editorial concerning

Unicode reference

Transition history

raised on 8 Aug 2003 by François Yergeau, on behalf of Internationalization WG

agreed on 14 Aug 2003

fixed

Acknowledgment cycle

announced by group on 29 Aug 2002

agreement by reviewer on 23 Sep 2003

yergeau-19: URI/IRIs [link to this issue]

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

• For resolution of relative URIs/IRIs, it should be clearly said that RFC 2396 (or it's successor) is relevant. IRIs don't change that at all, we just need to be careful that the implementations treat all non-ASCII characters as payload.
• It should be explicitly mentioned that DOM URIs can contain more than just US-ASCII.

Clarification concerning

DOM URIs

Transition history

raised on 8 Aug 2003 by François Yergeau, on behalf of Internationalization WG

agreed on 1 Oct 2003

The paragraph was rewording to include the proposed changes.

Acknowledgment cycle

announced by group on 2 Oct 2003

Action history

rancier-1: iterators for DOMConfiguration [link to this issue]

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()?

Proposal concerning

DOMConfiguration

Discussion history

11 Aug 2003, 12 Aug 2003

Transition history

raised on 11 Aug 2003 by Jeffery B. Rancier

agreed on 14 Aug 2003

added a read-only attribute parameterNameList, of type DOMStringList, on the DOMConfigurationList. This gives you the possiblity of iterating through the parameter names supported by the object. Note that this list can also contain parameter names defined outside the specification., i.e. extensions provided by the implementation.

Acknowledgment cycle

announced by group on 28 Aug 2002

ustiansky-1: What exception to raise? [link to this issue]

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?

Error concerning

Node.insertBefore

Discussion history

10 Sep 2003, 23 Sep 2003, 23 Sep 2003, 23 Sep 2003, 24 Sep 2003

Transition history

raised on 8 Sep 2003 by Vadim O. Ustiansky

stenback-1: setting Document.prefix [link to this issue]

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?

Error concerning

Node.prefix

Discussion history

18 Sep 2003

Transition history

raised on 18 Sep 2003 by Johnny Stenback

agreed on 15 Oct 2003

It is a no-op, similar to Node value.

Acknowledgment cycle

Not started

adler-1: "negative count" and unsigned counts [link to this issue]

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.

Error concerning

CharacterData.deleteData

Discussion history

19 Sep 2003, 19 Sep 2003, 19 Sep 2003, 20 Sep 2003, 24 Sep 2003, 24 Sep 2003

Transition history

raised on 19 Sep 2003 by Darin Adler

declined on 15 Oct 2003

One can expect an error but can't expect a specific error. This is decsribed in the DOMException interface already. No change needed to the specification.

Acknowledgment cycle

Not started

Action history