[Bug 6027] New: Extensions and Conformance

http://www.w3.org/Bugs/Public/show_bug.cgi?id=6027

           Summary: Extensions and Conformance
           Product: XPath / XQuery / XSLT
           Version: Recommendation
          Platform: PC
        OS/Version: Windows NT
            Status: NEW
          Severity: normal
          Priority: P2
         Component: XQuery
        AssignedTo: chamberl@...
        ReportedBy: mike@...
         QAContact: public-qt-comments@...


A number of (alleged) XQuery implementations ship with private extensions to
the XQuery grammar, to do things such as try/catch or grouping.

The specification is remarkably silent on the subject of whether such
implementations are conformant to the XQuery 1.0 specification or not. There
appears to be no specific requirement to detect and report all errors (clearly,
using such an extension is a static error according to the spec, but there
seems to be no obligation to report it).

The only thing the conformance section seems to say is the wonderfully woolly
"Minimal Conformance to this specification MUST include ... Support for
everything specified in this document (except....)".

As an implementor, I think the spec should provide guidance on whether
syntactic extensions are allowed or not.

My own view is that W3C specs should aim for a high level of interoperability,
but it might be that the database user community has lower expectations than
this.


--
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.

http://www.w3.org/Bugs/Public/show_bug.cgi?id=6027


Jonathan Robie <jonathan.robie@...> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jonathan.robie@...




--- Comment #1 from Jonathan Robie <jonathan.robie@...>  2008-09-23 16:06:41 ---
In practice, people are extending the language.

We originally offered option declarations
(http://www.w3.org/TR/xquery/#dt-option-declaration) and extension expressions
(http://www.w3.org/TR/xquery/#id-extension-expressions) for this purpose. My
memory is that we decided, at the time, not to add language to the spec
allowing people to extend the syntax in other ways, but other people seem to
remember differently, and I have not done the archaeology needed to be sure.

Obviously, these extensions themselves are not part of XQuery. We can't test
for syntactic extensions in our test suites without knowing what the extensions
are, which is just impractical.

I suspect the right answer may be to add language in the conformance section
requiring vendors to specify any syntactic extensions, and to very explicitly
warn vendors that the XQuery Working Group regards any such vendor extensions
as outside the scope of XQuery, and that we might well add to the XQuery
languages in ways that conflict with any extensions they make to the syntax.

We might also require a mode that does not accept any extensions.


--
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.

http://www.w3.org/Bugs/Public/show_bug.cgi?id=6027


Jonathan Robie <jonathan.robie@...> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED




--- Comment #2 from Jonathan Robie <jonathan.robie@...>  2008-11-03 21:16:08 ---
The specification is not completely silent on this matter if you look at the
text of error XPST0003:

<quote>
err:XPST0003
It is a static error if an expression is not a valid instance of the grammar
defined in A.1 EBNF.
</quote>

This is the error that is raised in case of a parse error:

<quote>
A parse error is raised as a static error [err:XPST0003].
</quote>

I think the right way forward is probably along these lines:

1. The XQuery specification governs only what we define. Any extensions to the
BNF are not part of the XQuery language.

2. Users can easily determine whether a query uses grammar not found in our
EBNF by using the XQuery applets. Thus, there is no need to ask vendors to
provide such a facility.

3. As a Working Group, we control the XQuery BNF. If a vendor extends the BNF
in their product, that has no bearing on extensions we make in the future, even
if they are incompatible with vendor extensions.

I will make a more formal proposal along these lines unless someone convinces
me to take a different approach.


--
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.