W3C home > Mailing lists > Public > public-qt-comments@w3.org > August 2002

Data Model WD: Error checking

From: Jeni Tennison <jeni@jenitennison.com>
Date: Mon, 19 Aug 2002 20:43:50 +0100
Message-ID: <59627256407.20020819204350@jenitennison.com>
To: public-qt-comments@w3.org


I think that there needs to be some clarification and consistency in
the Data Model WD regarding whether the
constructors/accessors/functions defined in the Data Model WD can
raise errors and what happens when they do.

I had been going to post a comment about error-checking in the node
constructor functions. For example, I expected something about what
happens if a comment is constructed with a value that contains "--" or
what happens if an element is constructed with a sequence of
attributes that includes two attributes with the same name.

Then I thought that you'd probably left out these things deliberately
because you wanted the host language for XPath (e.g. XSLT or XQuery)
to determine what happens in these cases, and didn't want to specify
error checking/handling within the data model.

But now I've come to Section 5, where it says (in the 5th paragraph):

  An atomic value can be constructed from its lexical representation.
  dm:atomic-value takes a string and a corresponding atomic type and
  constructs an atomic value in such a way to be consistent with
  validation. In particular the construction takes into consideration
  the facets of the type. **If the string does not represent a valid
  value of the type an error is raised**...

Is this mention of errors an oversight, or is there some rationale
behind some errors being detected and others not?

For what it's worth, I think that the data model *should* define all
the error checking that goes on when constructing nodes and values,
because that ensures that the various host languages of XPath detect
the same set of errors. The host languages themselves should be able
to decide what to do when an error gets raised, of course...

Jeni Tennison
Received on Monday, 19 August 2002 15:43:52 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:56:43 UTC