- From: Andrew Clover <and-w3@doxdesk.com>
- Date: Wed, 10 Dec 2003 17:14:29 +0000
- To: www-dom@w3.org
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.com http://www.doxdesk.com/
Received on Wednesday, 10 December 2003 12:33:00 UTC