W3C home > Mailing lists > Public > xml-names-issues@w3.org > July to September 1998

Error Handling

From: David Brownell <db@argon.Eng.Sun.COM>
Date: Sun, 16 Aug 1998 01:11:42 -0700
Message-Id: <199808160811.BAA04056@argon.eng.sun.com>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:13:38 UTC