W3C home > Mailing lists > Public > public-qt-comments@w3.org > August 2003

RE: Comments on http://www.w3.org/TR/xquery-operators/

From: Ashok Malhotra <ashokma@microsoft.com>
Date: Thu, 14 Aug 2003 07:47:08 -0700
Message-ID: <E5B814702B65CB4DA51644580E4853FB0A3CBE47@red-msg-12.redmond.corp.microsoft.com>
To: "Ian Davis" <ijdavis@softbase.math.uwaterloo.ca>, <public-qt-comments@w3.org>
Thanks you for your comments.  See inline

All the best, Ashok

> -----Original Message-----
> From: public-qt-comments-request@w3.org [mailto:public-qt-comments-
> request@w3.org] On Behalf Of Ian Davis
> Sent: Tuesday, August 12, 2003 9:28 AM
> To: public-qt-comments@w3.org
> Subject: Comments on http://www.w3.org/TR/xquery-operators/
> The XPath type functions comment(), node(), text(), processing-
> instruction(),
> node(), id(),  do not appear to be described in this document.  These
> functions may occur not just as a qualification in an XPath expression
> but as stand-alone functions within predicates that test the type of
> context node.  As such stand-alone functions they need to be both
> described
> in this standards document and bound to an explicit namespace, so that
> developer knows their behaviour and what their binding is.
> These functions should also be described in Appendix B.. Compatibility
> with
> XPath 1.0.
[AM] Adding functions for these selectors analogous to the op: functions
is an interesting idea but there is a great deal of resistance to adding
yet more functions to the F&O.
> The prefixes fn: op: xs: and xdt: are not explicitly mapped to
> While the bindings can be inferred I think a standard should not
> such inferences.
[AM] These prefixes are bound to namespaces.  See section 1.7 of the
> In section 5.1 it is stated that "The semantics of the constructor
> function xs:TYP (xdt:anyAtomicType) are identical to the semantics of
> "cast as xs:TYPE(xdt:anyAtomicType)".  This begs the question of
> such functions must be implemented/may be implemented/or like those
> functions
> bound to the op: namespace will not be implemented.  This issue should
> resolved since it impacts upon the portability of XQuery that employs
> functions in the xs: and xdt: namespaces, rather than a cast.
> Omitting these functions from those that must be implemented has the
> attractive
> property that all XQuery function which "must be implemented" reside
> the
> fn: namespace.
[AM] The conformance issues for the F&O have still to be dealt with.  We
will keep your suggestions in mind.
> I hope my comments are viewed as constructive ones..
> Regards, Ian Davis
Received on Thursday, 14 August 2003 10:47:37 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:45:13 UTC