- From: <bugzilla@wiggum.w3.org>
- Date: Tue, 20 Feb 2007 00:40:56 +0000
- To: public-qt-comments@w3.org
- CC:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=4273 ------- Comment #1 from simeon@us.ibm.com 2007-02-20 00:40 ------- Tim, This is a personal reply for now, as the working groups haven't gotten a chance to look at this yet. After a quick review of this, it seems that you may be right that there is a problem here. I think it may have some impact on type soundness. I.e., the static and dynamic types maybe inconsistent. In your example, this could lead to worse problems than the one you mention. For instance consider the following variation of your example: declare variable $x as element(a, xs:integer) external; declare variable $y as element() := $x; fn:lower-case($y) it seems that here the static typing will let this query pass (based on the fact that fn:data($y) will have xs:untypedAtomic as static type, and that xs:untypedAtomic can be promoted to xs:string. It also seem that it can happen for more cases than the one you mention, as in XML Schema, a typed with simple content (T1) can be derived from a type with mixed content (T2), and that a similar example could be built using this. Except if I missed something in the 'data on' rules (which I may have), this is a serious problem. A possible solution would be to change the rule for 'data on' to return xs:anyAtomicType in the case of type with mixed content, but I don't know if that would be an acceptable solution for you of the WGs. Note that I'm not sure we can do better, as we could always have the case you mention created for any atomic type so that seems a reasonable solution. Any feedback on this would be great. Thanks, - Jerome
Received on Tuesday, 20 February 2007 00:41:02 UTC