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

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



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