PSVI property preservation proposal (Pp-cubed :-)

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

Received on Tuesday, 13 May 2008 18:09:48 UTC