this is a german Web-Mirror of MHONARC.ORG powered by Domainunion AG

xsl-list
[Top] [All Lists]

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

2013-07-24 05:04:23
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


--~------------------------------------------------------------------
XSL-List info and archive:  https://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: https://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--