LS: Last minute comments on CR

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
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"
 - http://www.w3.org/2002/DOMLS (not 2003?)
 - "encoutered"
 - "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.
LSInput
 - "will only attempt to fetch the resource identified by the URI reference
*only*"
 - 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
 - "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, *i.e.* 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.
 - "A*n* LSInput" (?) (multiple times in doc)
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)
LSSerializer
 - "The XML data is written to a string or an output stream." -> Or to other
stuff like a webserver?
 - "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. 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?).
 - "Report a*n* fatal error"
 - "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... ;-)
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?


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?

Kind regards,

--Sander.

Received on Sunday, 30 November 2003 16:27:10 UTC