W3C home > Mailing lists > Public > public-xml-processing-model-comments@w3.org > September 2008

[closed] Re: more PSVI

From: Norman Walsh <ndw@nwalsh.com>
Date: Wed, 17 Sep 2008 06:37:32 -0400
To: public-xml-processing-model-comments@w3.org
Message-ID: <m2ej3jjbwz.fsf_-_@nwalsh.com>
Norman Walsh <ndw@nwalsh.com> writes:

> / James Fuller <james.fuller.2007@gmail.com> was heard to say:
> | thx goes to MohamedZ for pointing out the current WG debate as I had
> | my own PSVI questions.
> |
> | a few ruminations on PSVI;
> |
> | * what if we want to preserve PSVI annotations through a step that
> | does not require it ? e.g. something like a psvi-passthru attribute
> | though perhaps all this is a bit cumbersome for corner case?
>
> Most of the steps can change the structure of a document. That could
> make any of the PSVI properties invalid. I think it's better to say
> you have to (re)validate after you run those steps.
>
> | * what happens when p:xslt is using a validating XSLT v2.0 does the
> | existing psvi-required attribute need to be set to true then ?
>
> I think the behavior in the absence of @psvi-required is
> implementation-defined. The XSLT step is always free to produce PSVI
> annotations. You only need to put @psvi-required on the step that
> *consumes* XSLT output if you want to be sure that the implementation
> kept them.

The WG has considered this issue and concluded that only the following
editorial change was necessary to address it:

<note>
<para>A processor that supports passing PSVI properties between steps
is always free to do so. Even if
<code>psvi-required="false"</code> is explicitly specified, it is not
an error for a step to produce a result that includes additional PSVI
properties, provide it does not violate the constraints above.</para>
</note>


                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | Everything the same; everything
http://nwalsh.com/            | distinct.

Received on Wednesday, 17 September 2008 10:38:18 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:41:08 UTC