- From: <bugzilla@jessica.w3.org>
- Date: Thu, 30 Sep 2010 18:02:47 +0000
- To: public-qt-comments@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10882 Summary: [XQuery11] Why do external types introduced by external functions have to be subtypes of xs:anyAtomicType? Product: XPath / XQuery / XSLT Version: Member-only Editors Drafts Platform: PC OS/Version: Windows NT Status: NEW Severity: normal Priority: P2 Component: XQuery 1.1 AssignedTo: jonathan.robie@redhat.com ReportedBy: oliver@cbcl.co.uk QAContact: public-qt-comments@w3.org Group: XSLXQuery_WG Section 4.18 states: An XQuery implementation may augment the type system of [XQuery and XPath Data Model (XDM) 1.1] with additional types that are designed to facilitate exchange of data with host programming languages, or it may provide mechanisms for the user to define such types. For example, a type might be provided that encapsulates an object returned by an external function, such as an SQL database connection. These additional types, if defined, are considered to be derived by restriction from xs:anyAtomicType. This should say the implementation can augment XDM with additional item types, as I assume sequences of these types are also allowed. I would also like to know why these types must be subtypes of xs:anyAtomicType, and not just subtypes of item(). There are many expressions in XQuery that take arguments of type xs:anyAtomicType and behaviours would have to be defined for these expressions. I guess most of the time the behaviour would be to raise an error. If they don't behave like atomic values, then maybe they shouldn't be atomic values. For similar reasons that function items are not atomic values, atomic values are a often a poor fit for new types introduced. I would suggest changing the text to the following: An XQuery implementation may augment the type system of [XQuery and XPath Data Model (XDM) 1.1] with additional item types that are designed to facilitate exchange of data with host programming languages, or it may provide mechanisms for the user to define such types. For example, a type might be provided that encapsulates an object returned by an external function, such as an SQL database connection. These additional types, if defined, are considered to be derived by restriction from xs:anyAtomicType or subtypes of item() (but not node(), xs:anyAtomicType or function(*)). I hate to say it but should these types not also be mentioned in the data model? -- 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, 30 September 2010 18:02:48 UTC