Re: LS: Last minute comments on CR

On Sun, 2003-11-30 at 16:31, Sander Bos wrote:
> Hi there,
> 
> I reread the LS entire spec once more and here are some comments (per
> section). My apologies if it addresses things that have already come up
> before. With the exception of the Exception rant at the end (of which I
> sincerely hope it makes any sense....), it are all minor typo variety kinds
> of remarks.
> 
> 1.1
>  - "with the Loading and Saving *of* XML"
>  - "Provides the ability to examine and optionally remove nodes as they are
> being processed while serializing DOM nodes" -> Implies to me: changes the
> DOM while serializing

s/remove/filter/

> 1.2.3+4
>  - "and therefore *h*as no recommended meaning in ECMAScript"
> 1.3
> DOMIMplementationsLS
>  - "on the new*ly* created LSParser/LSSerializer" (not sure, not a native
> English speaker)
> LSParser
>  - "depenedent"

Fixed.

>  - http://www.w3.org/2002/DOMLS (not 2003?)

It's already in the implementations now. No reason to change this, so no
change.

>  - "encoutered"

Fixed.

>  - "In addition to the parameters recognized in [DOM Level 3 Core link]" ->
> still 4 clicks to reach actual link through HTML spec, at least in javadocs
> just one.

I added a direct link to DOMConfiguration.

> LSInput
>  - "will only attempt to fetch the resource identified by the URI reference
> *only*"

Fixed.

>  - What error should I throw if application tries to use LSInput without
> anything specified, implementation specific? Later I saw that LSSerializer
> has no-output-specified error

Correct. Added no-input-specified error.

>  - "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 sentence was removed from the LSResourceResolver description.

>  - "The namespace of the resource being resolved, *i.e.* the namespace of
> the XML Schema" -> e.g. instead, because other non-W3C resources may have
> namespace URIs too?

s/.../e.g. the target namespace of the XML Schema/. The "namespace of
the resource" is resource dependent and should be used a parameter of
the resource being resolved.

>  - systemId is not mentioned as can be null (unlike other params).

Changed. now it does.

>  Now I am
> totally out of my element here, but can LS be used for loading HTML DOMs?

I can be used to load XHTML documents, but we never intended the
interfaces for HTML documents.

>  - "A*n* LSInput" (?) (multiple times in doc)

Fixed.

> LSParserFilter
>  - Do I read it correctly that the children of entity reference nodes can be
> skipped or rejected, so I can get content of entity references that does not
> match the DTD in the result DOM? (just checking, no problem for us)

It was clarified as follows:
[[
method on the filter. 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.
]]

> LSSerializer
>  - "The XML data is written to a string or an output stream." -> Or to other
> stuff like a webserver?

Yes. the output stream could be attached to an HTTP connection. No
changes were made in the specification.

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

correct, "unless 'entities' parameter is set to false. As long as the
children of the entity reference are defined, you won't get an entity
reference node in the serialized content.

>  - "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. Now that I see there is an issue there, we prefer that
> serialization never changes DOM (note: we do not implement validation during
> serialization, perhaps that makes it very hard?).

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

>  - "Report a*n* fatal error"

Fixed.

>  - "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), I'd rather see that they default to true for LSSerializer, and
> leave setting them to false up to the implementation. (Especially like 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:
- namespaces can be set to false on LSSerializer.domConfig.
- namespace-declarations has effect if namespaces is set to false.
(since no namespace processing is done, the xmlns attributes are no
longer namespace declarations).

Regarding well-formed, this discussion is still on-going.

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

The sentence was removed. It has been pointed out that this attribute
can (and should) have an effect.

Philippe

Received on Monday, 5 January 2004 16:24:24 UTC