- From: Abel Braaksma <abel.braaksma@xs4all.nl>
- Date: Tue, 29 Sep 2015 13:45:52 +0200
- To: "Public Joint XSLT XQuery XPath" <public-xsl-query@w3.org>
> > > > > if(@a > 5) then xs:error(@a) else @a > > > > Which could be reported (probably in another world, I know) by processors > as: "XPTY0004: attribute type with value 8 is considered of invalid type", > which may more closely match the original meaning and use-cases in XSD > with xs:alternative. > > I’m not sure what you are getting at here. This one seems perfectly clear to > me: if the condition (@a > 5) is true, the expression raises a dynamic error > FORG0001. Why is this case a problem? My bad, I first had: let $err as xs:error := xs:error(@a) return if(@a > 5) then $err else @a Tested both with two processors, the first indeed doesn't throw except for @a>5, the expression with let compiles on one processor and sometimes throws, on another doesn't compile. > >> > >> let $x as xs:error := () > >> return 1 > > > > The possible outcomes here are : (1) the processor can optimize the variable > away and return 1, or (2) it can raise a type error because () is not a valid > instance of xs:error; it can raise this type error either (2a) statically or (2b) > dynamically. > > This case is no different from writing > > let $x as xs:integer := “London” return 1 > > so I fail to see why we find it troublesome. Because the text presently says that it must always raise.
Received on Tuesday, 29 September 2015 11:46:27 UTC