This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Should XQueryX allow documents that have top level element something other than xqx:Module? In Xquery it is clear that 1 is a valid expression and [1] is not, even though it matches the production Predicate, as the Xquery EBNF has a specified start production, and it is not possible to parse [1] starting from Module. Unfortunately XSD schema can not specify a starting (top level) element. It would be possible to restrict the top level elements by making all other element declarations local, but that would badly disrupt the current mechanisms of using substitution groups which can only refer to globally defined eleemnts. However an alternative would be to make this restriction in the stylesheet: <xsl:template match="/*"> <xsl:message terminate="yes">don't do that</xsl:message> </xsl:template> <xsl:template match="/xqx:module" priority="2"> .... Without such a restriction there are several examples of documents that are valid against the xqueryx schema, and generate valid xquery expressions when processed with the stylesheet, but which have rather unfortunate meanings. 1 ====================== <xqx:atomicType xmlns:xqx="http://www.w3.org/2005/XQueryX">a</xqx:atomicType> This is a and selects an element of that name, despite using xqx:atomicType ====================== 2 ====================== <xqx:resultExpr xmlns:xqx="http://www.w3.org/2005/XQueryX"> <xqx:contextItemExpr/> </xqx:resultExpr> this is . so the resultExpr element isn't restricted to typeswitch (it's intended usage) ====================== 3 ====================== <xqx:attributeList xmlns:xqx="http://www.w3.org/2005/XQueryX"> <xqx:attributeConstructor> <xqx:attributeName>x</xqx:attributeName> <xqx:attributeValue>y</xqx:attributeValue> </xqx:attributeConstructor> </xqx:attributeList> this doesn't construct attributes, but is instead x="y" which tests if the child element x is equal to the string "y" ====================== there are other examples, but these are all of the same basic type and would all be fixed if XqueryX documents were not allowed to start at arbitrary elements.
Thank you for your report and suggestion. This question has been considered in the past and it was felt at that time that (a)there are philosophical differences in opinion about whether XQueryX documents should be required to start at a specific level in the grammar or if complete flexibility is better, and (b)it was acceptable that not all syntactically valid (that is, validatable) XQueryX documents have defined semantics (in the sense that they might be translated to XQuery expressions that are either invalid syntactically or that have unexpected syntax). Your discussion indicates that this issue needs some more consideration, which will be started immediately.
The Working Group has discussed this comment and the proposed solution. We found your arguments persuasive and have adopted the proposed solution with the addition of text in the specification itself to highlight the new restriction. 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.
thanks, closing this.