This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
What is the intended meaning of xqx:constructorFunctionExpr In the schema and in the stylesheet it is equivalent to a one argument xqx:functionCallExpr. I could guess that it is intend to represent such constructs as xsl:int() but guessing the meaning of something by parsing a camelcased element name seems a rather strange specification. Assuming that this _is_ the intended meaning of xqx:constructorFunctionExpr then I think that a constructor function is syntactically and semantically a function call, and should be expressed with xqx:functionCallExpr, and xqx:constructorFunctionExpr should be deleted. If for some reason both were allowed, then xqx:constructorFunctionExpr should be restricted to _not_ use a type name of an in-scope atomic type as the function name. However It is hard to see how that requirement could be expressed in anything other than plain text. Neither the schema nor the stylesheet could enforce it.
Thanks for your report and discussion. As you infer, xwx:constructorFunctionExpr is syntactically equivalent to a one-argument xqx:functionCallExpr. Semantically, it is slightly different, at least in the correspondence to XQuery expressions. Constructors there are function-like in appearance, but behave more like casts. We will discuss your suggestion (that xqx:constructorFunctionExpr is unnecessary and can be replaced with xqx:functionCallExpr). In all frankness, I personally feel that the semantic distinction (even if only mental) justifies having two different elements.
I agree that they behave like casts, but casting is functional, this is not like a node test which also uses function syntax but is not a function. A system writing XQueryX (for example an XQuery to XQueryX convertor) has no way of knowing if a function is a "constructor function". In the case of the predefined schema types it may know, but in general once you have imported a schema or module or two then any xx:f(foo) call is just a call to some possibly system defined XPath function. It may be a constructor function corresponding to a schema defined type xx:f or it may be an external system call to some pile of Java, it isn't possible to tell by analysing the XQuery Expression and so it's not possible to make this distinction in the XQueryX. So, practically speaking, any XQueryX system _has_ to accept constructor functions marked up as FunctionCall. (Unless the stylesheet can somehow be made to flag an error, it is a normative requirement that such functions are accepted, as they translate to a valid XQuery Expression.) Given that, the separate element as an alternative markup for constructor functions seems to add little. A more practical yes-no question. My software currently converts the entire XQuery test suite to XQueryX without ever (having the possibility of) generating an xqx:constructorFunctionExpr element. Once the conformance criteria for XQueryX are finalised, is such a system going to be conformant? If the conformance requirements said that xqx:constructorFunctionExpr should be used, and I changed the system to use this for _all_ one-argument functions (practically speaking, the only alternative I have) would that be conformant? David
The semantic distinction between constructor functions and other functions is presumably that constructor functions have their own static type inferencing rules. In all other respects I think they can be treated as ordinary functions. And there are functions in the core library that have their own static type inferencing rules as well. It seems to me that a translator from XQuery to XQueryX shouldn't be required to have the rather deep level of semantic knowledge that's needed to distinguish the two cases. So I'm inclined to agree with David. Michael Kay
Looking at this comment from another perspective, I note that the XQueryX specification doesn't ever mention the static context. Is it intended that the translation from XQuery to XQueryX should make any use of the static context? If so, there's a constraint that the resulting XQueryX query must execute in a static context that resembles the original static context in certain unspecified ways. (The relevance here is that to know whether a function is a constructor function, you need to know the in-scope type definitions, and as a result, the XQueryX form of the query becomes intolerant of changes to the in-scope type definitions.) I can't see any other aspects of the static context that influence the translation, so I think it would be better to make the translation entirely context-free. I had a look to see what the translation is supposed to do about the static base URI, and it seems that nothing is said. That's perhaps a subject for a separate discussion. Michael Kay
Thanks for the ongoing discussion; it is very helpful. However, I have to emphasize that there is absolutely no requirement or intent that the XQueryX specification support any form of tranformation *from* XQuery to *to* XQueryX. I say this now because of Mike's remark in which he said "Is it intended that the translation from XQuery to XQueryX...". The answer to that is pretty close to the SQL null value, because there is no intent that there *be* a translation from XQuery to XQueryX, so there cannot be an answer about whether the static context should come into play. Having said that, here is my personal (not terribly considered) thought: If the transformation from XQueryX to XQuery, using the XQueryX stylesheet, transforms both xqx:constructorFunctionExpr and xqx:functionCallExpr into identical XQuery syntax, then what harm is there? It would mean that XQueryX generators that know enough about their environment to generate xqx:constructorFunctionExpr are free to do so when appropriate, and everybody is free to generate xqx:functionCallExpr in either situation. Why is that a problem? Because some XQueryX generators don't have that context and thus need to make a decision about whether or not to use xqx:constructorFunctionExpr? The answer to such generators is that there is no requirement that that use xqx:constructorFunctionExpr, but that they may if they wish.
> then what harm is there? It increases the burden on an XQueryX processor (it has to implement both elements) and (much) more importantly it works directly against the (presumed) intent of XQueryX. Having an XML syntax means that it is much easier to analyze and transform a Query Expression, however whenever you have multiple ways of encoding the same thing (in any language) such analysis becomes harder, and becomes exponentially harder the more duplicated terms you have. (Which is why parallel bug reports argue against node tests being encoded as XQueryX function calls (and boolean equality tests being encoded as AttributeConstructors). Some redundancy is probably inevitable but there is no need (and some harm) in introducing distinctions in XQueryX that are not present in XQuery. David
The Working Group has discussed this comment extensively. At the end of the discussion, the participants unanimously agreed that the finer granularity of distinctions offered by keeping xqx:constructorFunctionExpr and xqx:functionCallExpr distinct overshadows any simplifications that might be seen by any particular implementation of XQueryX. XQueryX generators that choose to generate xqx:functionCallExpr elements instead of xqx:constructorFunctionExpr will not be deemed nonconforming for that reasons, but other XQueryX generators may make the opposite choice in order to better capture the semantics of the query they are composing. Consequently, we determined that the bug will be marked WONTFIX. 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.
See closing comments in 2262