W3C home > Mailing lists > Public > www-dom@w3.org > January to March 2004

Re: Comments on DOM Level 3 Core/LS Nov-03 CR

From: Philippe Le Hegaret <plh@w3.org>
Date: Fri, 09 Jan 2004 12:12:25 -0500
To: Andrew Clover <and-w3@doxdesk.com>
Cc: WWW DOM <www-dom@w3.org>
Message-Id: <1073668344.9011.98.camel@jfouffa.w3.org>

On Wed, 2003-12-10 at 12:14, Andrew Clover wrote:
> =========
> 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.

If a node is not shown (using whatToShow) to the method acceptNode, the
node is accepted by default.

> Clarification: is it intentional that LSParser and LSSerializer use 'config'
> for DOMConfiguration properties rather than 'domConfig' as in Core?

Good catch. s/config/domConfig/

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


We explicitly discourage implementations to raise exception in the
filters, otherwise, it is implementation dependent.

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

If XML 1.1 -> fatal error.

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

oops, oops, oops, fixed.

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

Correct. Note that we removed the fatal error specific to CDATA section
to reuse the one propose in the well-formed parameter
"wf-invalid-character" as well.

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

The issue was removed without modification.

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

Somehow, we are uncomfortable in making this change at this stage, so
the issue was removed without any changes.

Received on Friday, 9 January 2004 12:12:47 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:12 UTC