[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Proposed requirements for XSLT 3.0 try/catch and

Subject: Re: Proposed requirements for XSLT 3.0 try/catch and validation
From: Michael Kay <mike@xxxxxxxxxxxx>
Date: Wed, 24 Jul 2013 11:04:02 +0100
Re:  Proposed requirements for XSLT 3.0 try/catch and
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

Current Thread

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.