- From: <bugzilla@jessica.w3.org>
- Date: Tue, 15 Sep 2015 02:42:09 +0000
- To: public-qt-comments@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26862 --- Comment #5 from C. M. Sperberg-McQueen <cmsmcq@blackmesatech.com> --- One possible way forward is to describe differently the way validation is performed on the parameters. If I'm reading the spec and our overall goals right, we want the effect of the rules to be: if a serialization parameter defined in our spec is used, it should be valid against the definition in the spec (including the schema), but it's legitimate to have other serialization parameters, not defined in the spec. (The PSVI is designed to provide just the information needed here, with a simple validation against the schema as given in the spec: unrecognized parameters will cause the output:serialization-parameters element to be invalid, but the individual parameters will be valid or invalid, and recorded as such. We cannot use that property here, though, because XQuery and XSLT both made the design error of confusing invalidity against a schema with an unconditional error condition, and our validation actions never return the PSVI if the validation root is invalid. It was a mistake to define our validation primitives this way, and we are now reaping the reward of that design mistake. And I would like to redeem my I-told-you-so chit now.) We can work around the problem by changing the rule to say NOT: validate the output:serialization-parameters element, and then raise an error if one of the parameters defined in the spec is invalid, but instead: validate each child of output:serialization-parameters individually, against the schema in the spec, and raise an error if any of them are invalid. Parameters not defined in the spec will not be valid, but they also won't be invalid: they will have validity = notKnown. (Unless, of course, our validation routines also treat notKnown as equivalent to invalid, in which case we must say to raise an error if any parameter defined in the spec is invalid.) So for (validate lax { document { . } }) /output:serialization-parameters /output:*[local-name() eq $param-name]/data(@value) we should (I think) read (validate lax { document { ./output:serialization-parameters /output:*[local-name() eq $param-name] } }) /data(@value) and for <xsl:sequence> <xsl:variable name="validated-instance"> <xsl:document validation="lax"> <xsl:sequence select="."/> </xsl:document> </xsl:variable> <xsl:sequence select="$validated-instance /output:serialization-parameters /output:*[local-name() eq $param-name]/data(@value)"/> </xsl:sequence> we should read <xsl:sequence> <xsl:variable name="validated-instance"> <xsl:document validation="lax"> <xsl:sequence select="./output:serialization-parameters /output:*[local-name() eq $param-name]"/> </xsl:document> </xsl:variable> <xsl:sequence select="$validated-instance /data(@value)"/> </xsl:sequence> I apologize that I have not worked through the underbrush of the QT specs' descriptions of schema validation to see whether there are any other gotchas. I intended to but am out of time. -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Tuesday, 15 September 2015 02:42:12 UTC