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

[Michael Kay <mike@xxxxxxxxxxxx>]

I completely forgot about the saxon:validate() extension function which was
designed to address this kind of use case. It's described here:

http://www.saxonica.com/documentation/#!functions/saxon/validate

It allows you to invoke schema validation in a way that doesn't fail if the
document is invalid, but rather returns information about the errors that were
found, including pointers to the invalid elements in the form of paths which
can be evaluated using xsl:evaluate. Give it a try and tell us how you get
on.

You might also find saxon:type() useful; given a node with a type annotation,
it gives you information about that type extracted from the schema component
model.

The design of both functions relies heavily on the new 3.0 features of maps
and higher-order functions.

Michael Kay
Saxonica


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.
>
> NEED YOUR HELP
>
> 	I seek your help in coming up with a complete set of requirements.
> 	Once completed, I will submit them to the XSLT 3.0 working group
> 	for their consideration.
>
> USE CASE: an XSLT program is doing schema-aware processing. The XSLT program
attempts to validate a context item within xsl:try. If validation fails, the
program attempts to repair the context item in xsl:catch. Here is the typical
structure:
>
>        <xsl:try>
>            <xsl:copy validation="lax">
>                <!-- Validation succeeded, process the context item -->
>            </xsl:copy>
>            <xsl:catch>
>                <!-- Validation failed, attempt to repair the context item
-->
>            </xsl:catch>
>        </xsl:try>
>
> So, validate the context item within the xsl:try. If validation fails, then
control falls to xsl:catch which attempts to repair the context item.
>
> Okay, let's figure out the requirements on a case-by-case basis:
>
> CASE #1: The context item is an element node that has child element nodes.
>
> Example: Suppose the context item is the Book element:
>
>        <Book>
>                <Title>Six Great Ideas</Title>
>                <Author>Mortimer J. Adler</Author>
>                <Date>1981</Date>
>                <ISBN>xxx0-02-072020-3</ISBN>
>                <Publisher>Collier Books</Publisher>
>        </Book>
>
> 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.
>
> Example: Suppose the context item is the Book element:
>
>        <Book>
>                <Title>Six Great Ideas</Title>
>                <Author>Mortimer J. Adler</Author>
>                <Date>1981</Date>
>                <ISBN>xxx0-02-072020-3</ISBN>
>                <Publisher>Collier Books</Publisher>
>        </Book>
>
> <xsl:copy validation="lax"> shall not fail validation even though one of its
child elements -- ISBN -- has an invalid value.
>
> If the context element is assessed invalid (without consideration of its
children), then validation fails and control falls into the xsl:catch. For
example, below I misspelled Book (note the 3 o's) so validation fails and
control falls into the xsl:catch where the XSLT program attempts to repair
<Boook>:
>
>        <Boook>
>                <Title>Six Great Ideas</Title>
>                <Author>Mortimer J. Adler</Author>
>                <Date>1981</Date>
>                <ISBN>xxx0-02-072020-3</ISBN>
>                <Publisher>Collier Books</Publisher>
>        </Boook>
>
> REQUIREMENT #2
>
> When control falls into xsl:catch, the context item is exactly the same as
the context item of the xsl:try. 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.
>
> CASE #2: The context item is an element node whose content is exclusively a
child text node.
>
> Example: Suppose the context item is the ISBN element:
>
>        <Book>
>                <Title>Six Great Ideas</Title>
>                <Author>Mortimer J. Adler</Author>
>                <Date>1981</Date>
>                <ISBN>xxx0-02-072020-3</ISBN>
>                <Publisher>Collier Books</Publisher>
>        </Book>
>
> The content of ISBN is just a text node.
>
> 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.
>
> For example, both of these will fail validation and result in control
falling into the xsl:catch:
>
>      <ISBN>xxx0-02-072020-3</ISBN>    <!-- Invalid value -->
>
>     <ISbN>0-02-072020-3</ISbN>           <!-- Valid value, but the element
is invalid -->
>
> Well, those are all the requirements that I can think of. No doubt I am
missing some requirements. Can you think of other requirements that are needed
to support this use case?
>
> Thanks!
>
> /Roger