W3C home > Mailing lists > Public > public-qt-comments@w3.org > September 2014

[Bug 26799] New: [XP31] operator namespace, for compatibility and for use in higher order functions

From: <bugzilla@jessica.w3.org>
Date: Sun, 14 Sep 2014 23:49:04 +0000
To: public-qt-comments@w3.org
Message-ID: <bug-26799-523@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26799

            Bug ID: 26799
           Summary: [XP31] operator namespace, for compatibility and for
                    use in higher order functions
           Product: XPath / XQuery / XSLT
           Version: Member-only Editors Drafts
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: XPath 3.1
          Assignee: jonathan.robie@gmail.com
          Reporter: abel.braaksma@xs4all.nl
        QA Contact: public-qt-comments@w3.org

Currently, the text under 1.2 Namespaces and prefixes, under the last bullet
point, says the following about operators:

<quote>
These functions are not available directly to users, and there is no
requirement that implementations should actually provide these functions.
</quote>

With the advent of higher order functions, it seems to make sense to allow
these "virtual" operator functions to be made available to end users. This can,
of course, be an implementation dependent feature.

The text above does not necessarily discourage implementers to provide such
functions, nor does it encourage it, but, other than other namespaces that are
not specifically bound to functions (like the output namespace and the error
namespace), the operator namespace is not defined.

I would propose to make this namespace explicit. For implementers that (want
to) provide such functions, i.e. for use with higher order functions or certain
types of dynamic programming, it would be nice if the namespace used for the
"op" prefix is the same for all of them.

A candidate namespace that comes to mind is
http://www.w3.org/2005/xpath-operators. Or alternatively, the standard function
namespace.

I think, if the WG considers such change, that the impact is minimal. It might
suffice to just mention the namespace and a sentence like "implementers that do
disclose these functions directly to end users, should use the namespace xxxx".

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
Received on Sunday, 14 September 2014 23:49:06 UTC

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