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

[Wolfgang Laun <wolfgang.laun@xxxxxxxxx>]

Perhaps a qualification of "validity" might help to clarify the
intent. For XML documents, there is a lexical level and, roughly
following the separation outlined by the XML Schema documentation,
there is "structure" and "data type".

I concentrate on the validity of data, according to simple data types.

Let's assume that there is a way to validate against an XML schema
where all simple types have been replaced on the fly by xs:string. I
suppose that, based on a valid structure, you could access all kinds
of nodes and validate their string data against the true data type in
the pertaining XML schema. Perhaps this can be achieved with today's
features in XSLT x.y - I'm not an expert.

-W


On 24/07/2013, Michael Kay <mike@xxxxxxxxxxxx> wrote:
> 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