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

Re: A single, all-encompassing data validation language - good

• From: "Anthony B. Coates (XML-Dev)" <abcoatesecure-xmldev@y...>
• To: "Andrew Welch" <andrew.j.welch@g...>
• Date: Thu, 09 Aug 2007 12:16:38 +0100

Perhaps the expression "single step" was misleading, as what I meant was  
that the validation of the input against a W3C XML Schema can be done  
during the XSLT/XQuery processing using a Schema-aware processor, so that  
you reduce the number of individual steps in the validation process by one.

As for how you use XSLT/XQuery to flag "Schematron level" validation  
failures, the situation is less clear and straightforward.  With XSLT, you  
can use <xsl:message> to terminate the script, but that means you only get  
to report one issue, and one-at-a-time reporting and correction of issues  
is a painful thing for users (as users of older Borland or Altova products  
would well remember).

On that basis, I prefer to use the XSLT/XQuery to write out an XML report  
of errors/warnings (aking to what Schematron does, although the Schematron  
XML reporting format isn't sufficient for my needs, as well as being all  
but undocumented).  I then check that XML output and throw an exception as  
appropriate if there are errors.  I wouldn't be using output validation  
except as a way to check that my error report has been correctly  
constructed by my script.

Cheers, Tony.

On Thu, 09 Aug 2007 11:55:30 +0100, Andrew Welch  
<andrew.j.welch@g...> wrote:

> On 8/9/07, Anthony B. Coates (XML-Dev)  
> <abcoatesecure-xmldev@y...> wrote:
>> I was not in any sense confused.  Perhaps you would care to re-read  
>> what I
>> wrote.  Cheers, Tony.
>
> Ok, sorry if I suggested you were and you weren't - you said:
>
> ====
> Schematron is a useful complement, but in the past, I've always found  
> that
> it, too, was too limited for what I needed, and so I found myself using
> XSLT instead.  Recently I've been using XQuery, which I think has a lot  
> to
> recommend it as a language for encoding a layer of data validation that  
> is
> at a level above what the schema languages do.  The integration of both
> XSLT 2.0 and XQuery (in some implementations) with W3C XML Schema means
> that you can do this level of data validation in the same single step as
> the Schema validation, which can be helpful.
> ====
>
> and I enquired which implementation you were referring that would
> allow you to "do this level of data validation in the same single step
> as
> the Schema validation", which you replied:
>
> ====
> I've seen it demonstrated using the commercial version of Saxon
> (www.saxonica.com).  I believe the Altova XML Query Processor also has
> support, although it may not be fully debugged yet (but is said to be
> making progress).  I'm sure there are others, but I don't know which
> ones.  The W3C list of XQuery implementations is here:
>
> http://www.w3.org/XML/Query/#implementations
>
> but this doesn't tell you which implement Schema-awareness.  I know that
> some implementations apparently do not intend to implement it.  I'm sure
> the vendors of XQuery processors that are Schema-aware won't be shy to
> post a note to that effect on this list, but it would be helpful if the
> W3C page captured that information, which it doesn't right now.
> ====
>
> ...which made me think you were just talking about schema aware
> transforms/XQueries.
>
> The only way I can think of using an SA processor with XSLT/XQuery to
> "validate" the source XML *and* apply some extra checks using
> XSLT/XQuery in a  *single step* is to use input validation (or copy
> the entire input to the result and use result validation for those
> processors that only support result validation) along with the kind of
> checks that would cause the validation to fail:
>
> <xsl:if test="$foo > $bar">
>   <xsl:message terminate="yes">Foo should never be greater than
> Bar</xsl:message>
> </xsl:if>
>
> Without terminating at that point you'd need to output something to
> the result and then have an extra step to check the result (which
> means a proprietary output format and some code to check the output,
> but you'd be able to get the full list of failures rather than just
> the first.)
>
> However, using input validation with a transform that terminates when
> a check fails is an appealing option, and available now...
>
> (I'm sure that's what you meant ;-)
>



-- 
Anthony B. Coates
Senior Partner
Miley Watts LLP
Experts In Data
UK: +44 (20) 8816 7700, US: +1 (239) 344 7700
Mobile/Cell: +44 (79) 0543 9026
Data standards participant: genericode, ISO 20022 (ISO 15022 XML),  
UN/CEFACT, MDDL, FpML, UBL.
http://www.mileywatts.com/

• Follow-Ups:
  • RE: A single, all-encompassing data validation language -good or bad for the marketplace?
    • From: Michael Kay <mike@s...>

• References:
  • Re: A single, all-encompassing data validation language - good or bad for the marketplace?
    • From: "Anthony B. Coates (XML-Dev)" <abcoatesecure-xmldev@y...>
  • Re: A single, all-encompassing data validation language - good or bad for the marketplace?
    • From: "Andrew Welch" <andrew.j.welch@g...>
  • Re: A single, all-encompassing data validation language - good or bad for the marketplace?
    • From: "Anthony B. Coates (XML-Dev)" <abcoatesecure-xmldev@y...>
  • Re: A single, all-encompassing data validation language - good or bad for the marketplace?
    • From: "Andrew Welch" <andrew.j.welch@g...>
  • Re: A single, all-encompassing data validation language - good or bad for the marketplace?
    • From: "Anthony B. Coates (XML-Dev)" <abcoatesecure-xmldev@y...>
  • Re: A single, all-encompassing data validation language - good or bad for the marketplace?
    • From: "Andrew Welch" <andrew.j.welch@g...>