Re: [xsl] Proposed requirements for XSLT 3.0 try/catch and validation

[Michael Kay <mike@xxxxxxxxxxxx>]

I think you're mixing a statement of requirements with the proposed design of
a solution. It would be useful to keep the two separate. I've no problem with
your requirements (I think), but would design the solution differently.


On 24 Jul 2013, at 10:36, Costello, Roger L. wrote:

> Hi Folks,
>
> I have a use case that I think is important and will benefit many people. I
would like for the XSLT 3.0 working group to support this use case. Below is
an initial set of requirements needed for this use case.
>
>
>
> REQUIREMENT #1
>
> <xsl:copy validation="lax"> shall not fail validation (i.e., the context
item is annotated valid) if the context item is valid without consideration of
its child elements.

What you're really asking for here is validation="local";  i.e. testing
whether the element is locally valid against a type, in the terminology of
XSD.

I think the main problem with this is that implementing this would require
fine-grained interaction between the XSLT processor and the schema processor.
There are XSLT implementations that use third-party schema processors (e.g.
XMLPrime uses the Microsoft .NET schema processor) and we would be reluctant
to do anything that made such a design impossible.
>
>
>
> REQUIREMENT #2
>
> When control falls into xsl:catch, the context item is exactly the same as
the context item of the xsl:try.

I think that's already one of the rules of try/catch.


> In fact, the context item is exactly as it was before the xsl:try -- it is
as though the xsl:try never happened. The xsl:try must not alter the context
item in any way if validation fails.
>
>
> REQUIREMENT #3
>
> <xsl:copy validation="lax"> shall fail validation (i.e., the context item is
annotated invalid) if the context item is invalid and/or its text is invalid.
>

We don't currently have any concept of annotating something as invalid.

I think what you are really looking for -- or at any rate, the way a W3C WG
would address you requirement -- is for XSLT to have more complete support of
the PSVI. I think you want a mode of validation in which invalidity is not an
error, but results in information about the nature and location of the
invalidity being made available to the application. That information is
essentially the PSVI, or some useful subset thereof.

There are some significant challenges in achieving this. One point to note is
that it's incompatible with streaming (the type of a node is known when you
see its start tag, but its validity against that type is only known when you
see the end tag).

In practical engineering terms, I think implementors might still have some
difficulty achieving this with third-party schema processors, because schema
processors don't all offer full access to the PSVI. But at least it would only
rely on features that conformant schema processors are supposed to provide.

I don't think I would tackle this requirement with a design based on
try/catch, I would tackle it with an approach in which invalidity is not a
dynamic error.

Michael Kay
Saxonica