- From: David Brownell <db@argon.Eng.Sun.COM>
- Date: Sun, 16 Aug 1998 01:11:42 -0700
- To: xml-names-issues@w3.org
Error handling isn't well enough specified in the current XML namespaces draft. If this is truly expected to be incorporated into an upcoming XML revision (1.1 or so) this must be defined using the same terminology (warning, error, fatal error). * Section 3 says prefixes "must" be associated with a namespace URI. --> If a prefix isn't so associated, is it a fatal error? --> Must this be reported during parsing? That is, does this spec increase parsing costs by requiring such state to be stacked even in event-based parsers which currently don't need to record such state? Parsers that build trees clearly have such state, so it's more natural to me to expect that a DOM implementation expose namespace information than require that a parser do so. (This gets again to "what is an XML processor". It should IMHO be possible to define it as "an event driven parser", even if that means the "XML processor" doesn't handle any of the namespace logic, but some other component of an XML system does so.) --> Or may these errors be reported on demand when namespaces are requested from something such as a DOM implementation? (This is clearly preferred from an implementation point of view; constructing in-memory data structures should be optional.) * Example, in section 4 prefixes starting "xml" (any case) are "reserved" ... what does that mean? What action should (or could) an XML processer perform given such a prefix? If it's not an error for a document to declare such a prefix, or for an XML processor to accept one, this doesn't belong in any sort of "constraint". * Section 7 on Conformance says various things need to be true. If they're not, would these be mortal or venial sins? That is, fatal or nonfatal errors? In general, the presentation of this doesn't seem as precise as that for the XML specification (which itself is not without problems) and so it's not a good specification to implement or test against. My suggestion would be to specify the behaviour of a "namespace processor" -- distinct from an XML processor! -- and define its behaviours in terms of the data provided to it by an XML processor (driven either by parsing events or by some parse tree). This processor would only need markup related data as input. Output would (in this draft) be either errors (fatal?) or annotations of element and attribute (and PI!) names to include a namespace and an unqualified "local part". - Dave
Received on Sunday, 16 August 1998 04:11:28 UTC