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

Re: XProc Minutes 27 Sep 2007

From: Jeni Tennison <jeni@jenitennison.com>
Date: Thu, 27 Sep 2007 20:01:04 +0100
Message-ID: <46FBFDF0.9040009@jenitennison.com>
To: public-xml-processing-model-wg <public-xml-processing-model-wg@w3.org>

Norman Walsh wrote:
> See http://www.w3.org/XML/XProc/2007/09/27-minutes
>   Saxonica comments, sections 1 and 2
>    ->
>    http://lists.w3.org/Archives/Public/public-xml-processing-model-comments/2007Sep/0022.html
>    Alex: What about point 8?
>    Murray: Do we need to have a section that makes our vagueness more
>    explicit.
>    <alexmilowski> "Infoset Processing
>    <alexmilowski> At a minimum, an XML document is represented and
>    manipulated as an XML Information Set. The use of supersets, augmented
>    information sets, or data models that can be represented or conceptualized
>    as information sets should be allowed, and in some instances, encouraged
>    (e.g. for the XPath 2.0 Data Model).
>    <alexmilowski> "
>    <alexmilowski> We say that in our requirements document.
>    Norm: What's now in 2.6.1 probably needs to be further up in the document
>    Alex: I think we need to say something explicit about being based on the
>    Infoset
>    Murray: I think what goes between the steps is a putative XML document. It
>    could be an infoset, it could be an XDM, it could be an XPath 1.0 NodeSet,
>    it could be any number of different things. And it depends on your
>    implementation how you're going to do that.
>    ... We want you to bear in mind however, that it is something that could
>    be mapped into an XML document. We're talking about a theoretical, or
>    putative, document.
>    Alex: That's what using infoset would give us.
>    Norm: I think what we have in 2.6.1 is probably good enough, we should
>    just move it up.
>    <scribe> ACTION: Norm to ask Mike if he thinks that might be good enough.
>    [recorded in http://www.w3.org/2007/09/27-xproc-minutes.html#action06[23]]

This is the problem:

Say you have a p:validate-with-xml-schema step before a p:xslt2 step. 
Schema-Aware XSLT 2.0 uses the PSVI to build an XPath 2.0 data model. 
The types in the data model can be used for matching/selecting nodes in 
the stylesheet.

In this case, if the "XML document" passed between the two steps is a 
PSVI, the types will be present and the stylesheet will work as 
designed. But if the "XML document" passed between the two steps is 
*not* a PSVI, the types won't be present and the stylesheet won't work 
(nodes won't be selected/matched as desired).

So there's a real possibility that two conforming implementations will 
give significantly different results.

I think there are three options:

1. We say that implementations must not pass PSVIs between steps (which 
means that to support Schema-Aware XSLT 2.0, the xslt2 step itself will 
have to do schema validation; we've ruled out this option in the wording 
Alex quoted above).

2. We say that implementations *must* pass PSVIs (or XDMs, but in any 
case augmented Infosets) between steps (which is a fairly significant 
implementation burden, and I believe we ruled out early on in the process).

3. We say that it's implementation-defined whether Infosets or PSVIs get 
passed between steps, and provide a Note that describes the effect (as 
discussed above).

Of course I'd prefer to avoid implementation-defined items if possible, 
but I think it's the only thing we can do. It's far better that we 
explicitly make it implementation-defined than leave it as woolly as it 
is now, in my opinion.

We also need to say whether the steps do or don't preserve the 
augmentations in an augmented Infoset. For example, if I stick a 
p:add-attribute between the p:validate-with-xml-schema and p:xslt2 steps 
above, does the XSLT 2.0 receive the types or not? (I think the steps 
probably should preserve augmentations except where the type or validity 
of the document might be changed by their actions; adding an attribute 
might change validity, so type information shouldn't be preserved in 
that case, for example.)


Jeni Tennison
Received on Thursday, 27 September 2007 19:01:19 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:32:44 UTC