This is the official issues list for the DOM Level 3 Core Last Call period.
This document contains a list of issues regarding the DOM Level 3 Core specification Last Call period. All comments or issues regarding the specification or this document must be reported to www-dom@w3.org (public archives) before July 31, 2003. After this date, we don't guarantee to take your comments into account before moving to Candidate Recommendation.
An XML version of this issues' list is also available.
DOM Working Group members: see also the W3C Member-only bugzilla for non-official issues.
Color key: error warning note
| Id: Title | State | Type | Open actions | Ack. |
|---|---|---|---|---|
| ustiansky-1 : What exception to raise? | no decision (raised) | error | ||
| aillon-1 : Document.xmlVersion | agreed | clarification | No reply from reviewer | |
| yergeau-1 : nodeName? | agreed | clarification | No reply from reviewer | |
| yergeau-2 : Attribute values and entity references | agreed | clarification | No reply from reviewer | |
| yergeau-3 : Entity declarations | agreed | clarification | No reply from reviewer | |
| yergeau-19 : URI/IRIs | agreed | clarification | No reply from reviewer | |
| lesch-1 : isWhitespaceInElementContent or isWhiteSpaceInElementContent ? | agreed | editorial | No reply from reviewer | |
| yergeau-4 : redundant if? | agreed | editorial | No reply from reviewer | |
| yergeau-5 : Namespace algorithm | agreed | editorial | No reply from reviewer | |
| yergeau-7 : xmlVersion mapping | agreed | editorial | No reply from reviewer | |
| yergeau-8 : notations mapping | agreed | editorial | No reply from reviewer | |
| yergeau-11 : CDATA sections and Infoset | agreed | editorial | No reply from reviewer | |
| arnold-2 : attribute name case | agreed | error | No response to reviewer | |
| yergeau-6 : actualEncoding vs xmlEncoding | agreed | error | No reply from reviewer | |
| yergeau-9 : no namespace and Infoset | agreed | error | No reply from reviewer | |
| yergeau-10 : previous and next sibling mapping | agreed | error | No reply from reviewer | |
| stenback-1 : setting Document.prefix | agreed | error | No response to reviewer | |
| arnold-5 : getName vs getLocalName | agreed | proposal | No reply from reviewer | |
| nichol-1 : Node.namespaceURI | agreed | proposal | No reply from reviewer | |
| manian-1 : getDOMImplementation(s) | agreed | proposal | No reply from reviewer | |
| manian-2 : unspecified standalone | agreed | proposal | No reply from reviewer | |
| manian-3 : whitespaces | agreed | proposal | No reply from reviewer | |
| arnold-18a : isWhitespaceInElementContent() or isWhitespaceInElementContent ? | agreed | proposal | No reply from reviewer | |
| rancier-1 : iterators for DOMConfiguration | agreed | proposal | No reply from reviewer | |
| arnold-8 : actual encoding? | agreed | clarification | Agreement | |
| yergeau-15 : CharacterData methods and character normalization | agreed | clarification | No reply from reviewer | |
| arnold-7 : DOMImplementationSource | agreed | proposal | Agreement | |
| yergeau-14 : normalize() and character normalization | agreed | proposal | No reply from reviewer | |
| clover-4 : logically adjacent and wholeText | agreed | clarification | Agreement | |
| clover-5 : error types | agreed | clarification | Agreement | |
| arnold-3 : hasFeature and Core 1.0 | agreed | clarification | Agreement | |
| arnold-24 : handleErrors | agreed | clarification | Agreement | |
| yergeau-12 : actualEncoding and xmlEncoding | agreed | clarification | Agreement | |
| clover-1 : an application data | agreed | editorial | Agreement | |
| clover-7 : Text.data | agreed | editorial | Agreement | |
| arnold-4 : ordered collection | agreed | editorial | Agreement | |
| yergeau-18 : Unicode 4.0 | agreed | editorial | Agreement | |
| yergeau-13 : renameNode and invalid characters | agreed | error | Agreement | |
| adams-1 : DOMImplementationRegistry behavior | agreed | proposal | Agreement | |
| arnold-6 : exceptions in NameList | agreed | proposal | Agreement | |
| clover-8 : DOMError severity | agreed | proposal | Agreement | |
| arnold-25 : byte and character offsets | agreed | proposal | Agreement | |
| stenius-1 : derived types | agreed | request | Agreement | |
| arnold-1 : NameList: contains and containsNS | agreed | request | Agreement | |
| arnold-16 : Position comparison | declined | clarification | No reply from reviewer | |
| adler-1 : "negative count" and unsigned counts | declined | error | No response to reviewer | |
| arnold-18 : isId() or isId ? | declined | proposal | No reply from reviewer | |
| arnold-22 : XML Schema and DTD types | declined | proposal | No reply from reviewer | |
| arnold-23 : nested and anonymous types | declined | proposal | No reply from reviewer | |
| clover-2 : DOM features and plus (+) sign | declined | clarification | Agreement | |
| clover-6 : whitespace-in-element-content | declined | clarification | Agreement | |
| arnold-11 : recognized XML encoding | declined | clarification | Agreement | |
| arnold-15 : Attributes and renameNode | declined | clarification | Agreement | |
| arnold-9 : config or configuration? | declined | editorial | Agreement | |
| importNode-1 : adoptNode and importNode | declined | editorial | Agreement | |
| clover-3 : renameNode and non-namespace nodes | declined | proposal | Agreement | |
| arnold-10 : documentURI and valid URIs | declined | proposal | Agreement | |
| arnold-14 : adoptNode return value | declined | proposal | Agreement | |
| arnold-17 : getFeature and hasFeature | declined | proposal | Agreement | |
| arnold-19 : DOMError.clone() | declined | proposal | Agreement | |
| arnold-20 : User data and event handling | declined | proposal | Agreement | |
| arnold-21 : anonymous types | declined | proposal | Agreement | |
| yergeau-16 : "cdata-sections" default must be false | declined | proposal | Agreement | |
| arnold-13 : adoptNode and importNode | declined initial suggestion, agreed on follow-up | editorial | Proposal incorporated | |
| yergeau-17 : check character normalization? | declined | clarification | Objection | |
| arnold-12 : Requirements of standalone | declined | proposal | Agreement |
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?
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?
Document.xmlVersion should be
null if not dealing with XML.
The description should say that the exception is raised is the XML feature is *not* supported.
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.
We consider this section overly vague. At least two points should be improved:
The paragraph was rewording to include the proposed changes.
send a proposal to fix DOM URIs section.
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 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.
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.
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.
The section was reworded a bit.
look at this section Appendix B1.1 for futher changes (if necessary)
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.
it should be clarified that CDATASection nodes cannot occur from an infoset mapping, since the infoset doesn't contain CDATA section boundaries.
" 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.
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."
propose an erratum for DOM Level 2 HTML
To contact Opera and Konqueror regarding the erratum
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.
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 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?
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.
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.
add a descriptive paragraph for NameLists in Validation.
Reply to Curt, as soon as Ben is done.
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.
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.
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.
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.
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()?
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.
Not adequately explained. Is this the encoding at the time of parsing? Do subsequent saves change the value? initialEncoding might be better.
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.
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.
This question was reconsidered.
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.
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.
The description of the DOMString interface has been changed to reflect the fact that only normalizeDocument has the control over the character normalization.
some rewording would be appreciated.
This question was reconsidered.
The paragraph was rewording to include the change on Node.normalize() as well.
we need somewhere a section that says nothing do character normalization except normalizeDocument when requested.
Characters are fully-normalized according to the rules
defined in [CharModel] supplemented by the definitions
of relevant constructs from Section 2.13 of [XML 1.1],
if the normalization happened at load time, or by
calling the method
Document.normalizeDocument() (in both
cases, the parameter
"normalize-characters" needs to be
true). Note that, with the exception of
Document.normalizeDocument(),
manipulating characters using DOM methods does not
preserve a fully-normalized text.
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.
We clarified the description of getDOMimplementation as follows:
" This method returns the first item of the list returned by getDOMImplementationList. "
getDOMImplementationList() seemed to be
required of an implementation source but never used by a
DOMImplementationRegistry.
This question was reconsidered.
DOMImplementationRegistry.getDOMImplementationList was broken and has been fixed.
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.
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.
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.
This question was reconsidered.
The issue was reconsidered and we agreed with the recommendation.
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?
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.
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.
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. "
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 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.
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.
The repeated wording "an application data" is rather odd; 'data' is of course plural.
"The DOMString attribute of the Text node..." - surely "The data attribute...".
" ordered collection of parallel pairs of name and namespace values "
should read
ordered collection of qualified names
We change NameList: "ordered collection of parallel pairs of name and namespace values (which could be null values)"
add a descriptive paragraph for NameLists in Validation.
Reply to Curt, as soon as Ben is done.
The reference to Unicode 3.0 should be updated to Unicode 4.0, ISBN 0-321-18578-1.
fixed
Should specify, like createAttribute() and others, that an
INVALID_CHARACTER_ERR exception can be
thrown, depending on the "xmlVersion" attribute.
fixed
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:
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;
List;
DOMImplementationSource will be returned
when more than one supports the same features.
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.
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.
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:
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.
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.
SEVERITY_FATAL_ERROR will always cause
processing to stop. Return value from
handleError is ignored.
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.
offset has been splitted in byteOffset and utf16Offset (since the DOM deals with utf-16 units, and not characters).
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.
isDerivedFrom has been added to
TypeInfo.
add this issue on the f2f agenda.
Consider the following addition for the
NameList interface:
boolean contains(DOMString name); boolean containsNS(DOMString namespaceURI, DOMString localName);
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.
contains and containsNS have been added.
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.
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...
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.
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.
Add this to the FAQ and reply to the DOM TS list.
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.
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.
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"/>
An anonymous type could be nested many levels down in the content model, a containingEle