W3C home > Mailing lists > Public > public-qt-comments@w3.org > September 2015

[Bug 26862] serialize-xml-007a should expect SEPM0017

From: <bugzilla@jessica.w3.org>
Date: Tue, 15 Sep 2015 02:42:09 +0000
To: public-qt-comments@w3.org
Message-ID: <bug-26862-523-VOcoU9VV9L@http.www.w3.org/Bugs/Public/>

--- 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

(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:*[local-name() eq $param-name]/data(@value)

we should (I think) read

  (validate lax { document { ./output:serialization-parameters
     /output:*[local-name() eq $param-name] } })

and for

    <xsl:variable name="validated-instance">
      <xsl:document validation="lax">
        <xsl:sequence select="."/>
    <xsl:sequence select="$validated-instance
                          /output:*[local-name() eq

we should read

    <xsl:variable name="validated-instance">
      <xsl:document validation="lax">
        <xsl:sequence select="./output:serialization-parameters
                          /output:*[local-name() eq $param-name]"/>
    <xsl:sequence select="$validated-instance

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:57:56 UTC