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 11:51:18
I completely forgot about the saxon:validate() extension function which was 
designed to address this kind of use case. It's described here:

https://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



--~------------------------------------------------------------------
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>
--~--



--~------------------------------------------------------------------
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>
--~--