- From: James Fuller <james.fuller.2007@gmail.com>
- Date: Wed, 17 Sep 2008 12:39:10 +0200
- To: "Norman Walsh" <ndw@nwalsh.com>
- Cc: public-xml-processing-model-comments@w3.org
thx, sounds good to me On Wed, Sep 17, 2008 at 12:37 PM, Norman Walsh <ndw@nwalsh.com> wrote: > 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:39:46 UTC