Re: PSVI property preservation proposal (Pp-cubed :-)

Well

I think that there is one use case that is not covered

The one where I want to make an library that could be used, by someone
who asked for p:psvi-required or not

I want for the case where the caller asks for p:psvi-required to
validate between each steps that looses PSVI

I also want for the case the caller don't asks for p:psvi required TO
NOT validate between each steps

Mohamed

On Tue, May 13, 2008 at 8:09 PM, Henry S. Thompson <ht@inf.ed.ac.uk> wrote:
>
>  -----BEGIN PGP SIGNED MESSAGE-----
>  Hash: SHA1
>
>  Further to action 1 from our telcon of 8 May, herewith a proposal for
>  what we do about PSVI support.
>
>  1) There's a system property called p:psvi-supported, which tells you
>    whether the implementation supports the PSVI to the minimal level
>    required (see below) or not.  Its value is global, i.e. _not_
>    sensitive to where/when you ask about it. (Already in Editors'
>    Draft of 8 May [1])
>
>  2) There's a step annotation psvi-required, which can appear on
>    p:declare-step, p:pipeline or p:library.  In the first two cases,
>    it signals that the step being declared/defined requires PSVI
>    support, and that a dynamic error should be raised if that step is
>    ever about to be executed by a processor for which p:psvi-supported
>    is false.
>
>    When psvi-required appears on p:library with value 'true', it is as
>    if all its p:pipeline and p:declare-step children (note, _not_
>    decendents) which do not themselves specify a value for
>    psvi-required get the value 'true' for it.
>
>    (Already in Editors' Draft of 8 May, but semantics needs tweaking
>    to bring in to line with the above)
>
>  3) Some information needs to be added to section A.3 Infoset
>    Conformance about what PSVI support means.  Something along the
>    following lines:
>
>      To support the PSVI
>
>      a) Implementations MUST transmit faithfully any PSVI properties
>         produced on step outputs to the steps whose inputs are
>         connected to them.
>
>      b) If the p:iteration-source of a p:for-each or the
>         p:viewport-source of a p:viewport is connected to an output
>         which includes PSVI properties, those properties MUST also be
>         included in the documents presented on the special 'current'
>         port defined by those steps. [Note about validity of document
>         element in viewport case?]
>
>      c) If an output of a compound step is bound to an output which
>         includes PSVI properties, those properties MUST also be
>         present on the output of the compound step, _except_ for the
>         output of p:viewport, which MUST NOT contain any PSVI
>         properties.
>
>      d) If an implementation supports XPath 2.0, construction of the
>         data model with respect to which evaluation of XPath
>         expressions and match patterns is carried out SHOULD, when it
>         is based on a document from an output which contains PSVI
>         properties, take advantage of such PSVI information as much as
>         possible.
>
>      e) Except as specified in (a)--(d) above, and in the descriptions
>         herein of the p:xslt, p:validate-with-xml-schema and p:xquery
>         steps, implementations MUST NOT include PSVI properties in the
>         outputs of the steps defined in this specification.  It is
>         *implementation-defined* what PSVI properties, if any, are
>         produced by extension steps.
>
>  4) Add brief statements to p:xslt and p:xquery that it is
>    *implementation-defined* what PSVI properties they output.
>
>  I think that's it.
>
>  ht
>
>  [1] http://www.w3.org/XML/XProc/docs/langspec.html
>  - --
>   Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh
>                      Half-time member of W3C Team
>     2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440
>             Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk
>                    URL: http://www.ltg.ed.ac.uk/~ht/
>  [mail really from me _always_ has this .sig -- mail without it is forged spam]
>  -----BEGIN PGP SIGNATURE-----
>  Version: GnuPG v1.2.6 (GNU/Linux)
>
>  iD8DBQFIKdlLkjnJixAXWBoRAoNVAJ9iViqFTwM90dWjRERnLNwSFle2UACfSNU6
>  TcqGk/1XtnkTrsEYyf7d3Sg=
>  =B00X
>  -----END PGP SIGNATURE-----
>
>



-- 
Innovimax SARL
Consulting, Training & XML Development
9, impasse des Orteaux
75020 Paris
Tel : +33 9 52 475787
Fax : +33 1 4356 1746
http://www.innovimax.fr
RCS Paris 488.018.631
SARL au capital de 10.000 €

Received on Tuesday, 13 May 2008 21:24:19 UTC