[Bug 5915] [FS] rules for XPST0005

http://www.w3.org/Bugs/Public/show_bug.cgi?id=5915





--- Comment #6 from Michael Dyck <jmdyck@ibiblio.org>  2008-10-09 09:44:14 ---
(In reply to comment #2)
> Consider
> 
> U = (T1 | T2)
> T1 <: xs:untypedAtomic?
> not(T2 <: xs:untypedAtomic?)
> 
> Following the static typing rules in 7.1.1:
> 
> statEnv  |-  not(U <: xs:untypedAtomic?)
> -------------------------------------------------------------
> statEnv |-  (FS-URI,"convert-operand")( U, Type2) : U
> 
> This is clearly wrong.

I agree with your analysis, and agree that the result is unsound. I will
propose some replacement rules to fix this. 

The new rules will probably change the static type of
    fs:convert-operand(data(()), 1)
to 'empty', which gets us back to your original point, namely:
-- since it has a static type of 'empty', it's subject to the rule in
   section 4, and
-- since it doesn't qualify as an exception, it must raise an error,
-- which you suspect is unintended.

I'm not sure it's unintended. Looking at the XQuery/XPath spec, it seems
clear from the wording in 2.3.1 that the expression
    1 + ()
should raise an error if the processor supports the Static Typing Feature.
And, back in FS-land,
    fs:convert-operand(data(()), 1)
will raise an error, thus agreeing with the XQuery/XPath spec.

It would be more interesting if there were an example expression where the
two specs *didn't* agree on whether XPST0005 should be raised.


-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Thursday, 9 October 2008 09:44:25 UTC