- From: Michael Rys <mrys@microsoft.com>
- Date: Wed, 17 Oct 2007 18:59:36 -0700
- To: Bill Patton <bpatton_temp8345@cogneticsystems.com>, "public-qt-comments@w3.org" <public-qt-comments@w3.org>
Your assumption is correct. Note that the formal semantics gives you a rather weak static type and implementations can provide more precise static types. Best regards Michael -----Original Message----- From: public-qt-comments-request@w3.org [mailto:public-qt-comments-request@w3.org] On Behalf Of Bill Patton Sent: Wednesday, October 17, 2007 9:31 AM To: public-qt-comments@w3.org Subject: static type rules for fn:doc() Dear sirs, Does anyone know how fn:doc(expr) should be statically typed? The Formal Semantics document at 7.2.5 does not seem to be clear on this. It states that if the type of the fn:doc(uri) is not statically known then the type is "document?", but "document" is not defined. I suspect that "document" refers to document {...} defined in 3.5.4 as: [document-node()]sequencetype == document { (element * of type xs:anyType | text | comment | processing-instruction)* } with the "document" of 7.2.5 being used as an abbreviation for the document {...} expression. To my way of thinking, there are three cases when typeing fn:doc(expr): 1) During static type checking we do not know if the document will be constructed from an XDM Infoset or PSVI. In this case, the most specific type is: document { (element * of type xs:anyType | text | comment | processing-instruction)* }? which is the formal type for document-node()? 2) The type of fn:doc(uri) is statically known to be T. 3) It is statically known that fn:doc(uri) will be constructed from an XDM Infoset. In this case the formal type of the document is more accurately: document { (element * of type xs:untyped | text | comment | processing-instruction)* } If we use (3) rather than (1) for typeing fn:doc(uri) when running XQTS we get roughly 100 fewer static type errors. The downside of using the more accurate static type is that static types inferred for queries are often more complex with types like, element(*, xs:untyped) replacing types like element(). -- This message uses a temporary e-mail address to defeat spammers. For the latest contact information please call (678) 533-4405
Received on Thursday, 18 October 2007 01:59:52 UTC