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

["Costello, Roger L." <costello@xxxxxxxxx>]

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