Home. 
.

transparent

transparent

transparent

Altova Mailing List Archives


Re: [xml-dev] A single, all-encompassing data validation language - good or bad for the marketplace?

From: "Anthony B. Coates (XML-Dev)" <abcoatesecure-xmldev@-----.--.-->
To: "Andrew Welch" <andrew.j.welch@-----.--->
Date: 8/9/2007 11:17:00 AM
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/


transparent
Print
Mail
Like It
Disclaimer
.

These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on www.altova.com/list/index.html. Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.

.
.

transparent

transparent