This list contains the issues raised during the Candidate Recommendation phases of DOM Level 3 Core and Load/Save.
Comments or additions regarding this list must be sent to the DOM public mailing.
Color key: error warning note
| Id: Title | State | Type | Open actions | Ack. |
|---|---|---|---|---|
| ls-sander-2 : systemId and relative URI reference | agreed | clarification | No reply from reviewer | |
| ls-sander-3 : namespace and resource resolver | agreed | clarification | No reply from reviewer | |
| ls-sander-4 : systemID, resource resolver, and HTML | agreed | clarification | No reply from reviewer | |
| ls-sander-7 : entities, serialization, and expansion | agreed | clarification | No reply from reviewer | |
| ls-sander-8 : serialization and DOM tree | agreed | clarification | No reply from reviewer | |
| ls-sander-9 : parameters "well-formed", "namespaces", and "namespace-declarations" | agreed | clarification | No reply from reviewer | |
| ls-sander-10 : encoding | agreed | clarification | No reply from reviewer | |
| ls-sander-11 : default error handler | agreed | clarification | No reply from reviewer | |
| andrew1 : DOM Level 2 and future | agreed | clarification | Agreement | |
| andrew2 : ud-isId-ifying | agreed | clarification | Agreement | |
| ls-curt-1 : LSProgressEvent.position and totalSize | agreed | clarification | Agreement | |
| ls-andrew-1 : LSSerializer and whatToShow | agreed | clarification | Agreement | |
| ls-andrew-2 : config, xmlConfig, or domConfig? | agreed | clarification | Agreement | |
| ls-andrew-6 : invalid characters | agreed | clarification | Agreement | |
| ls-sander-5 : LSParserFilter and entities | agreed | clarification | Proposal incorporated | |
| robin1 : Hesitation on setAttributeNS | declined | clarification |
| No reply from reviewer |
| ls-ramesh-1 : Clarification needed regarding default value of newLine in DOMSerializer of DOM L3 LS spec | declined | clarification | No reply from reviewer | |
| Ian1 : node.insertBefore(child, child) | declined | clarification | Agreement | |
| andrew4 : canonical-form and "special" parameters | declined | clarification | Agreement | |
| curt1 : Parameter name inconsistency between NameList.contains and DOMStringList.contains | agreed | error | Agreement | |
| ls-andrew-4 : canonical-form and discard-default-content | agreed | error | Agreement | |
| ls-andrew-5 : canonical-form and xml-declaration | agreed | error | Agreement | |
| andrew3 : handle and exceptions | agreed | proposal | Agreement | |
| ls-andrew-3 : Filters and exceptions | agreed | proposal | Agreement | |
| oleg1 : Element.getIdAttribute() and Element.getIdAttributeNode | declined | proposal | No reply from reviewer | |
| chris1 : node.insertBefore( child ) | declined | proposal | No reply from reviewer | |
| ls-sander-1 : namespace for LS Events | declined | proposal | No reply from reviewer | |
| ls-andrew-7 : LSSerializer-iucd-issue | declined | proposal | Agreement |
"If the system identifier is a URI, the LSParser must resolve it fully before calling this method." What does this mean exactly, is there an example? Relative URIs like 'bla/bla.dtd' are passed as is, right?
"The namespace of the resource being resolved, *e.g.* the namespace of the XML Schema" e.g. instead, because other non-W3C resources may have namespace URIs too?
systemId is not mentioned as can be
null (unlike other params). Now I am totally
out of my element here, but can LS be used for loading
HTML DOMs? And if so, so HTML not allow only public id in
DOCTYPE? If systemId is obligatory, then maybe nice to
make that explicit.
"EntityReference nodes are serialized as an entity reference of the form "&entityName;" in the output. Child nodes (the expansion) of the entity reference are ignored." Unless 'entities' parameter is set to false, right? If not, I really want to be able to get rid of entity references during serialization without touching the DOM.
"The character normalization process affects only the data as it is being written; it does not alter the DOM's view of the document after serialization has completed." Does this not simply apply to everything related to serialization? (if so, useful to mention in intro) Same for namespace fixup. There might an issue there, as we prefer that serialization never changes DOM (Note: we do not implement validation during serialization, perhaps that makes it very hard?).
An issue regarding this problem was left in the specification for the attention of the implementators. We clarified that yes, the transformation done during the serilization do not affect the DOM tree, only the serialized content.
"The parameters "well-formed", "namespaces", and "namespace-declarations" cannot be set to false" These seem to give a fair bit of overhead (lot more checks), we'd rather see that they default to true for LSSerializer, and leave setting them to false up to the implementation. (Especially since this would be exactly the kind of thing someone would write a conformance test for...
Regarding namespaces and namespaces-declarations, it has been clarified that:
Regarding well-formed, this discussion is still on-going.
"This attribute (encoding) has no effect when outputting to a character stream." nitpick, well it does for the XML declaration written out and for splitting CDATA sections I suppose?
What happens if, as a user, I do not bother to set an error handler, and IOExceptions occur. Maybe a core issue but they don't have that many IOException (or other serious caught Exceptions that can seemingly dissappear into thin air) opportunities like LS has. The more I think about it the stranger I think it is a Load/ Save spec defines so little in the way of error handling. Am I missing something?
So what happens in case of an IOException, it's wrapped in a DOMError (where the exception is an object in the Java binding...) and gets passed to the error handler but that thing can't even rethrow it (because no throws is defined for handleError, and IOException is a caught exception).So far we cheated in our implementation (still had DOMSystemException, I figured the error handling stuff would be changed), and threw the original exception when no error-handler was set.
Again I may be missing something but the way I interpret the spec now if I do
Document willThisBeNull =
implementation.createLSParser(....).parseURI("file:///c:/does_not_exist.xml");I get no exception? DOMError on core says "A SEVERITY_FATAL_ERROR will cause the normal processing to stop and the return value of DOMErrorHandler.handleError() is ignored". Okay, so we stop processing, but what does that mean? Not a DOMException I suppose?
Section 1.3.3 paragraph 6 contains the following caveat:
"The DOM Level 2 does not support any mechanism to resolve namespace prefixes. For all of these reasons, use of such entities and entity references should be avoided or used with extreme care. A future Level of the DOM may include some additional support for handling these."
Is this still relevant to DOM 3 given the ability of normalizeDocument to fix up unbound prefixes?
Yes, since you can still play with DOM Level 1 nodes, DOM Level 2 nodes, and entities. DOM Level 3 does include a mechanism to fix namespace prefixes but cannot fix that case. The paragraph has been updated to match the current version of DOM however.
The text for Element.SetIdAttribute[NS|Node] is only accurate if the isId parameter holds true. The text should be amended to reflect the possibility of un-isId-ifying attributes.
The description of these methods do not specify what units (bytes, UTF-16 units) are used to report the position and total size.
There should be a mechanism (a value of -1 for example) to indicate that a totalSize could not be determined or estimated.
It should state clearly that when an LS[Parser|Serializer]Filter declines to be shown a particular type of node through its whatToShow property, the node is by default skipped, but that nodes that are never shown to filters due to their nodeType are by default accepted.
Is it intentional that LSParser and LSSerializer use 'config' for DOMConfiguration properties rather than 'domConfig' as in Core?
LSSerializer paragraph 8: "any occurrence of a character that cannot be represented in the output character encoding is reported as a fatal error" - a DOMError fatal error, I presume. Suggest mentioning 'wf-invalid-character-in-node-name' as the error that should be raised for the given example, if this is indeed correct.
Is it correct that the children of entity reference nodes can be skipped or rejected, so one can get content of entity references that does not match the DTD in the result DOM?
It was clarified as follows:
"If the parameter "entities" is set to true, the entity reference nodes are passed to the filter, but not its children. If it is set to false, the children of the entity reference are passed to the filter, but not the entity reference nodes since they are replaced by their expansions. Note that, as described by the parameter "entities", entity reference nodes to non-defined entities are always passed to the filter."
How about:
When entities is true, if the entity reference node is skipped, the child nodes are processed with the filter receiving callbacks for them, as if "entities" had been set to false just for this one entity reference;
The proposal was incorporated.
Node.setAttributeNS() and friends with
similar parameters has text to stricly forbid a qName with
a prefix for a null nsURI, but nothing on whether it is
legal to use it with a defined nsURI, and a qName that
doesn't contain a prefix part.
Most implementations seem to accept it, and then fail to serialise it properly. Some rightfully complain that you can't have a namespace URI on an attribute that doesn't have a prefix. This is a sorry state of affairs :)
So it would be nice to see it resolved either way: either it is clearly flagged as an error, or it is clearly allowed, with indication of how the implementation may produce the prefix (not overwriting the one of that attribute if it exists, using a prefix in scope if there's one, generating one).
The specification is fine since our definition qualifiedName allows an optional prefix. This is a serialization issue and is already handled by our namespace normalization algorithm. We will add the test however.
Java binding of DOM L3 LS contains unclear javadoc for getNewLine and setNewLine methods of DOMSerializer class.
From the javadoc it is not clear that what should getNewLine return in case setNewLine is not called before ( default value ). Whether "null" should be returned or the "platform default end-of-line sequence"?
The javadoc for setNewLine is exactly same as getNewLine? There is need for changing the javadoc for getNewLine and setNewLine and make it different to define specific purpose of each method.
Whether the intention is that when "null" value is passed to setNewLine, then the end-of-line sequence need to be defaulted to platform specific one? And getNewLine should never return "null".
Here is snippet of javadoc for getNewLine/setNewLine.
/**
* The end-of-line sequence of characters to be used in the XML being
* written out. Any string is supported, but these are the recommended
* end-of-line sequences (using other character sequences than these
* recommended ones can result in a document that is either not
* serializable or not well-formed):
* <dl>
* <dt><code>null</code></dt>
* <dd> Use a default
* end-of-line sequence. DOM implementations should choose the default
* to match the usual convention for text files in the environment being
* used. Implementations must choose a default sequence that matches one
* of those allowed by section 2.11, "End-of-Line Handling" in [XML 1.0], if the
* serialized content is XML 1.0 or section 2.11, "End-of-Line Handling"
* in [XML 1.1], if the
* serialized content is XML 1.1. </dd>
* <dt>CR</dt>
* <dd>The carriage-return character (#xD).</dd>
* <dt>
* CR-LF</dt>
* <dd> The carriage-return and line-feed characters (#xD #xA). </dd>
* <dt>LF</dt>
* <dd> The
* line-feed character (#xA). </dd>
* </dl>
* <br>The default value for this attribute is <code>null</code>.
*/
public String getNewLine();We changed the description to get the default value (implementation specific end-of-line sequence) on retrieval, and on setting, use the value null to set it to its default value.
Regarding the javadoc, it is automatically generated from the specification. It would require a huge work to make the text of attributes specific for their setter and getter.
Does the spec define what should happen with
node.insertBefore(child, child)?
From my reading of the spec [1], what should happen is that first the child node should be removed ("If the newChild is already in the tree, it is first removed."), then a "NOT_FOUND_ERR" exception should be thrown, since the node is no longer in the tree and so can't be found.
This isn't useful, and isn't what UAs appear to have implemented. Based on this testcase, Opera, Mozilla, IE6, and Safari all simply ignore the call, not changing the DOM and not raising any exceptions.
Could the spec be clarified to specify this interoperable behaviour?
It is indeed the behavior of common UAs, but unfortunately, it is notthe case on Xerces. Given that at least one significant implementationis following the specification, we cannot render it non conformant bymodifying the specification to accomodate and describe the behaviors ofthe UA implementations. node.insertBefore(child, child) andnode.replaceChild(child, child) are now described as "implementationdependent" in the specification. It does not clarify anything exceptthat DOM applications should now be aware of no interoperability forthose cases.
The DOMConfiguration parameter
"canonical-form" is currently neither fish
nor fowl: it has its own state (like most parameters), but
is not directly readable as it encompasses other
parameters (as with "infoset"). It may be too
late to change this now, but it would be nice if it could
be made to behave like "infoset", with no
internal state of its own. A few parameters would need to
be added to control eg. attribute/namespace declaration
order and removal, empty element short forms (which might
be a useful option to have in its own right) and doctype
removal (could repurpose LS's
"disallow-doctype" for that).
We made it a real parameter, with its own state. It still does set other parameters when set to true but modifying those other parameters will also unset canonical-form.
This also matches the behavior of canonical-form and format-pretty-print on the LSSerializer.
The parameter in NameList.contains is "name".
The parameter in DOMStringList.contains is
"str". Having a consistent parameter name simplifies
DOMTS. Document.getElementsByTagName and
Element.getElementsByTagName has a similar
conflict which is addressed by patching the spec to make
them identical. I may need to do a similar hack but it
would be good if the conflict could eventually be
eliminated.
Shouldn't the DOMConfiguration parameter 'canonical-form' set 'discard-default-content' to false?
Should 'canonical-form' have an effect on 'xml-declaration'? There seems to be some potential interaction here, esp. regarding XML 1.1.
"Any exceptions thrown inside a UserDataHandler will be ignored."
Does this really mean that user code, when called-back, may throw any exception and it'll be silently caught and swallowed, rather than allowed to propagate to the caller? This seems really bad news for debugging, especially in languages like Python where an Exception covers a multitude of sins (eg. KeyboardInterrupt, MemoryError, etc.); it is also a marked change from the existing callback arrangement of NodeFilter in DOM Level 2 Traversal. If the aim is merely to avoid having to declare interfaces that 'throws Throwable' in Java, couldn't this be left as an issue for the language bindings?
This behavior has been in the DOM since DOM Level 2. DOM Level 2 Events does indicate, when using EventListener:
"Any exceptions thrown inside an EventListener will not stop propagation of the event. It will continue processing any additional EventListener in the described manner. "
The group decided to stick with the current status quo, i.e. no change in the specification. True enough, ignoring exceptions can render your implementation unstable, but the intent is to prevent DOM applications to rely on behaviors resulting from an exception thrown in the handler.
Fully agree, but I'd expect such a reliance situation to occur more readily with the exceptions-swallowed model than the exceptions-propagated model - it is possible a faulty filter throwing execeptions would go entirely unnoticed.
This question was reconsidered.
We reconsidered our change and change the specification as follows for DataUserHandler, LSParserFilter, and LSSerializerFilter:
"DOM applications must not raised exceptions in a filter. The effect of throwing exceptions from a filter is DOM implementation dependent."
paragraph 5: "The LSParser ignores any exception
raised in the filter". Same issue/query as with
UserDataHandler. If it really is the
intention that exceptions are silently swallowed, how
should an LSParser treat an exception in
response to a call to acceptNode/startElement? Skip?
Accept?
If there are explicit setIdAttribute[|NS|Node]() methods then it seems quite logical that explicit getIdAttribute() should also be present.
There is a misunderstanding of what setIdAttribute is doing. It is saying that this attribute is of type id. There can be more than one attribute of type id, so getIdAttribute could return a list of attributes. We already have isId, that should be enough.
Why does this method, when no second argument is
specified, append the child? Node.appendChild
already does this - why not make
Node.insertBefore() insert at the beginning
by default?
Opportunity for added functionality aside, consider that a loop to add elements to the end of a list is simple:
for( i = 0; i < len; i++ ) node.appendChild( list[ i ] );
Whether the node begins empty or not. But a loop to add elements to the beginning is not:
for( i = 0; i < len; i++ ) {
if( node.childNodes.length == 0 )
last = node.appendChild( list[ i ] );
else
node.insertBefore( list[ i ], last );
}While I realize the for loop could be optimized, that's not the point. There are many varied cases where objects must be repeatedly added to any number of lists, which may or may not be empty at the time. The call may not happen directly inside of a for loop, but several methods down, the top-most being called in such a loop, etc.
Why not make this call as simple as:
node.insertBefore( list[ i ] );?
The namespace for LS events is http://www.w3.org/2002/DOMLS. not 2003?
Issue LSSerializer-iucd-issue: IMO it would make sense to move this parameter into the DOM Level 3 Core spec, and the error/warning should be defined there.
Last update: $Date: 2004/01/27 23:02:23 $
This page was generated as part of the Extensible Issue Tracking System (ExIT)
Copyright © 2003 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply. Your interactions with this site are in accordance with our public and Member privacy statements.