W3C home > Mailing lists > Public > public-qt-comments@w3.org > October 2008

[Bug 5915] [FS] rules for XPST0005

From: <bugzilla@wiggum.w3.org>
Date: Thu, 09 Oct 2008 09:44:15 +0000
To: public-qt-comments@w3.org
Message-Id: <E1Kns47-0005Rs-33@farnsworth.w3.org>

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:57:24 UTC