CORE
====
Clarification: 1.3.3 paragraph 6 contains a caveat referring to DOM Level 2
and 'a future version of the DOM', is this still relevant to DOM 3 given the
ability of normalizeDocument to fix up unbound prefixes?
Clarification: 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.
Proposal: UserDataHandler.handle: "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 strikes me as
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?
Editorial: Node.cloneNode: "[...] has no parent; (parentNode is null.) and no
user data." - superfluous semicolon and period in parentheses.
Editorial: DOMConfiguration parameter order has element-content-whitespace
listed at the end. The intention was probably to list the parameters
alphabetically.
Error: Document.normalizeDocument refers to Document.xmlConfig, should
be domConfig.
Editorial: TypeInfo: "The TypeInfo interface represent a type" - 'represents'.
Editorial: DOMConfiguration: 'canonical-form': "the DocumentType node is
removed from the tree if any and superfluous namespace [...]" - sentence is
tricky to parse, suggest "the DocumentType node (if any) is removed from the
tree, and superfluous [...]".
Proposal: 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).
LOAD/SAVE
=========
Clarification: 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. If indeed that is
the case - I am guessing from the behaviour of NodeFilter in Traversal.
Clarification: is it intentional that LSParser and LSSerializer use 'config'
for DOMConfiguration properties rather than 'domConfig' as in Core?
LSParser, 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?
Clarification: shouldn't the DOMConfiguration parameter 'canonical-form' set
'discard-default-content' to false?
Clarification: should 'canonical-form' have an effect on 'xml-declaration'?
There seems to be some potential interaction here, esp. regarding XML 1.1.
Error: LSResourceResolver paragraph 2 refers to LSParser.resourceResolver,
this should be the DOMConfiguration parameter 'resource-resolver'.
Editorial: LSResourceResolver.resolveResource and LSSerializer paragraph 11:
"URI's" - no apostrophe.
Error: LSParser.parseWithContext and LSSerializer.write: still refers to
Document.actualEncoding, should be inputEncoding.
Clarification: 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.
> Issue LSSerializer-change-DOM: We may take back what we say in the above
> paragraph depending on feedback from implementors
No, thanks. It makes sense to me that LSSerializer should not make changes to
the Document object model it is operating on. It is not difficult for a DOM
to clone the Document and normalise+serialise the clone for serialisation
options that are problematic.
> 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.
Agree, is useful for normalizeDocument.
--
Andrew Clover
mailto:and@doxdesk.comhttp://www.doxdesk.com/