This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The schema has: <xsd:complexType name="functionCallExpr"> <xsd:complexContent> <xsd:extension base="expr"> <xsd:sequence> <xsd:element name="functionName" type="QName"/> <xsd:element name="arguments" type="exprList" minOccurs="0"/> so the arguments child may be omitted (it also may be present, but empty) If however it is omitted then the stylesheet does not put () after the function name, and the construct will be an Xpath to select a child element not a function call. minOccurs="0" should be deleted, and a 0-argument function should be represented by a functionCallExpr with an empty (but present) arguments child. David
Many thanks for your comment and for finding this problem. We will certainly fix it as soon as possible, although a slightly different solution might be adopted.
We have made a change to the stylesheet, but not the schema, to fix the bug that you identified. Specifically, the stylesheet now tests for the presence of the xqx:arguments child. If it is present, then the stylesheet behaves as it does today; otherwise, an empty set of parens is generated. Please let us know if you agree with this resolution of your issue, by adding a comment to the issue record and changing the Status of the issue to Closed. Or, if you do not agree with this resolution, please add a comment explaining why. If you wish to appeal the WG's decision to the Director, then also change the Status of the record to Reopened. If you wish to record your dissent, but do not wish to appeal the decision to the Director, then change the Status of the record to Closed. If we do not hear from you in the next two weeks, we will assume you agree with the WG decision.
Leaving this one not-closed, although I haven't(yet) taken the formal step of re-opening it. The change you have made means that there are two equivalent ways to encode every 0-ary function, you can have either no xqx:arguments child, or an empty xqx:arguments. There is no semantic difference that is being encoded here, so why allow both forms? I think it would be much better to either force xqx:arguments to be present (my original suggestion) or to allow it to be empty but to change its type to a non-empty list. (I have no preference between these two alternatives) David
> or to allow it to be empty but to change its type to a non-empty list. ^^^^^^ sorry, I meant to say: or to allow it to be omitted but to change its type to a non-empty list.
The XML Query WG discussed this comment, including your pushback. We observe that there exist other examples in XQueryX where it is possible to represent the same XQuery syntax both as the absence of an element and as the presence of an element with no content. (See mainModule and prolog, for example.) Because of those other examples, the fact that neither they nor this example are actually broken, and the need to expend resources fixing more serious problems, the WG declines to make the additional restriction that you have suggested. Please let us know if you are able to accept this resolution of your issue, by adding a comment to the issue record and changing the Status of the issue to Closed. Or, if you do not agree with this resolution, please add a comment explaining why. If you wish to appeal the WG's decision to the Director, then also change the Status of the record to Reopened. If you wish to record your dissent, but do not wish to appeal the decision to the Director, then change the Status of the record to Closed. If we do not hear from you in the next two weeks, we will assume you agree with the WG decision.
Actually I'd fix the other examples as well. But they are not so serious. A query has at most one prolog so having two ways there does not cause serious exponential blow up in the number of ways an expression can be encoded. Currently every 0-ary function has two ways of being encoded (with or without xqx:arguments) and every 1-ary function has two ways of being encoded (with functioncall or constructorfunction) thus a typical query with half a dozen such functions can be encoded in 64 ways. One would expect that a benefit of an xml encoding is that it is nearer to the abstract syntax tree and abstracts away many syntactic differences that one finds in a text encoding, which should make the xml encoded version more amenable to analysis and transformation. These encoding variations mean that XqueryX is looking like it will have _more_ syntactic variation than the xquery form, which is somewhat strange. I don't really accept the "no resources to make the change" argument, as the existing draft is broken (as acknowledged) so some change has/had to be made anyway. Changing the schema to delete the minOccurs attribute would have not taken any more resources than the change that was made to the stylesheet. I realise that you are having a F2F now, and so several issues are likely to be being decided, I'll defer a decision on whether to close or re-open this report once the proposed resolution of all the issues is more clear. (this open/closed business makes the discussion seem rather more adversarial than one would like, but as I'm sure you know this is intended as constructive reviewing rather than spanners in works...) David
While it is true that there may be 2^n ways of encoding queries, the WG participants do not believe that there is any practical implications of that formula. Surely, any given XQueryX generator will have been written to choose only one of the two ways to express 0-ary functions and only one of the two ways to express 1-ary functions; we doubt seriously that any XQueryX generator will be written in such a way that it dynamically changes its style at each function invocation. Another, admittedly weaker, reason is that we are aware of XQueryX documents "in the wild" that have already used the 0-ary encoding published in the 2005-09-15 Working Draft. This reason, as weak as it may be, helped push the WG into the decision to be liberal in the case of 0-ary function encodings. Please let us know if you agree with this resolution of your issue, by adding a comment to the issue record and changing the Status of the issue to Closed. Or, if you do not agree with this resolution, please add a comment explaining why. If you wish to appeal the WG's decision to the Director, then also change the Status of the record to Reopened. If you wish to record your dissent, but do not wish to appeal the decision to the Director, then change the Status of the record to Closed. If we do not hear from you in the next two weeks, we will assume you agree with the WG decision. (P.S., We most certainly do not feel that this dialog is confrontational in any way. While it has taken on a more formal "feel", we think that it is wise to do so at this stage of processing so that the record is absolutely clear.)
My apologies: I intended to mark this bug as "WONTFIX" rather than "FIXED". Instead of re-opening the bug just to change that resolution, I'm including this note for clarification.
> we doubt seriously that any XQueryX generator will > be written in such a way that it dynamically changes its style I'm seriously tempted to prove you wrong the WG wrong. I have an XQX generator (that can produce schema-valid instances from all the xquery test suite). Currently it always uses functioncall, and always uses xqx:arguments but it would only be a moment's job to change it to alternate between the two choices. As you may guess, I think the decision is harmful to xqueryx and in the end this (and similar decisions on functioncall etc) will mean that there will have to be a profile "canonical xqueryx" with a tighter schema that removes all these choices. However it's clear that a) I haven't persuaded the WG that as a general principle, having multiple encoding forms is bad, and b) Given a, there is no point in arguing the same issue in multiple bugzilla threads on individual items where the disagreement stems from this basically different strategic view. so on this issue (and similar ones) I propose that I state disagreement in textual form in the comment, but I do _not_ raise objections in the sense of the W3C process, and I close the reports.