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 stylesheet has <xsl:text>processing-instruction</xsl:text> <xsl:value-of select="$LPAREN"/> <xsl:value-of select="*"/> <xsl:value-of select="$RPAREN"/> </xsl:template> value-of select="*" will (in xslt1) silently discard all but the first node. this looks a bit dangereous, but actually I wonder why the schema allows more than one node here. The Xquery grammar has [89 (Core)] PITest ::= <"processing-instruction" "("> (NCName | StringLiteral)? ")" so 0-or-1 node that is NCName-or-String However the XqueryX schema has <xsd:element name="piTest"> <xsd:complexType> <xsd:choice minOccurs="0"> <xsd:element name="piTarget" type="xsd:NCName"/> <xsd:element name="piValue" type="xsd:string"/> </xsd:choice> </xsd:complexType> </xsd:element> so any number of "pitargets" and "pivalues". Shouldn't the schema be brought int o line with the grammar, or, since the string version is explictly only there for XPath1 compatibility, and equivalent to the use of an NCName, the XQueryX version only really needs to model the child of pitest being 0-or-1 NCName. David
In fact, the XQueryX schema as currently written does *NOT* allow more than one node in the place you cite. The relevant schema snippet (from your message) is: <xsd:element name="piTest"> <xsd:complexType> <xsd:choice minOccurs="0"> <xsd:element name="piTarget" type="xsd:NCName"/> <xsd:element name="piValue" type="xsd:string"/> </xsd:choice> </xsd:complexType> </xsd:element> I believe that your concern stems from the fact that the <xsd:choice> element has a minOccurs attribute, but no maxOccurs attribute. It is a common error to think that the absence of a maxOccurs attribute means "any number of occurrences". In fact, according to XML Schema, section 3.3.2, XML Representation of Element Declaration Schema Components (http://www.w3.org/TR/xmlschema-1/#declare-element), the default value for maxOccurs (when it is not specified) is 1. Therefore, we believe that this is not an error in the XQueryX specification. To avoid this sort of confusion in the future, we will add an explicit maxOccurs="1" attribute to such places (this harms nothing and has the advantage of making the Schema more nearly self-documenting).
> we believe that this is not an error in the XQueryX specification. I agree. Sorry I was wrong: feel free to close this report as notabug or whatever the category is.
Thanks for your agreement with my initial response. Based on your response, I have changed the status to CLOSED.