[Bug 29119] [XP31] xs:error always raises a type error

https://www.w3.org/Bugs/Public/show_bug.cgi?id=29119

--- Comment #15 from Michael Kay <mike@saxonica.com> ---
At present types aren't first-class values so they are always hard-coded. But
in XSLT, we now have the ability to manipulate the stylesheet at compile time
through static expressions so you can write something like

<xsl:param name="x" _as="$input-type-x"/>
<xsl:param name="y" _as="$input-type-y"/>

where $input-type-x and $input-type-y are static (compile-time) variables
containing the name of a type. You can do something similar in XQuery if you
generate XQuery code. Once you have this capability, you very quickly run up
against the requirement to say "in these circumstances, $y is not relevant and
must not be supplied". That is, the set of permitted values of $y is empty;
it's convenient to have a name for this, and xs:error serves the purpose.

Of course, if xs:error didn't exist, then there are plenty of other ways the
user could devise a type that doesn't have any valid instances. For example,
you can restrict xs:string with the facets length=4 and pattern="z". But XSD
chose to give us a named built-in type for this purpose, so it's silly to make
users invent their own. But a user-defined type with no instances would behave
exactly like a built-in type with no instances: we're not doing anything
strange here.

(We had all these discussions when we introduced xs:error to XPath 3.0. I'm
really not sure why we are having them again now).

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Tuesday, 6 October 2015 11:03:34 UTC