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

Re: Validation, Schematron and the role attribute

  • From: Rick Jelliffe <rjelliffe@allette.com.au>
  • To: Frank Steimke <f-steimke@berger-und-steimke.de>
  • Date: Tue, 23 May 2017 23:58:41 +1000

Re:  Validation
If you are using Schematron strictly to validate to get a simple valid/invalid result, then any failed-assert or successful-report means invalid.

If you are going beyond that, and using the role attribute to get different degrees of validity, or using reports to do feature extraction, etc, then the simple default valid/invalid result is irrelevant to your case. When I write schemas, I only use assert to state what should be, and I only use report when doing some feature extraction or ad hoc pattern detection. 

If you have some assertions that pertain to validity, and some that pertain to feature extraction, check whether they actually are unrelated patterns, and group the rules into their appropriate patterns.


(Also, you would be better making your assertion into an assertion: a natural language statement of what is expected. If you just have a "whoops someone farted" kind of assertion text, you are not creating a schema you are creating a kind of unit test: the purpose of a schema is to state the rules clearly and precisely. That kind of text is fine for a report element, though.)

Kind regards,
Rick

On 23 May 2017 05:04, "Frank Steimke" <f-steimke@berger-und-steimke.de> wrote:

Hi,

we are playing with different aspects of validation of xml documents. We would like to understand how validation with Schematron really works.

 

As an example let’s have a look at a language for reporting examination results:

 

# examination grade from A (best) to F (failed)

grade = "A" | "B" | "C" | "D" | "E" | "F"

# exam result consists of pupils name and the grades for English and math

result =

    element result {

        element name { text },

        element english { grade },

        element math { grade }

    }

# examination results for a group of pupils

start = element results { result+ }

 

I would like to use schematron to enforce a business rule: for each individual there must not be two or more results in the list. I would also use Schematron to inform me when someone is detected who is very good in math and good enough in English (kind of a side-effect). Which leads to this schema:

 

<sch:pattern>

        <sch:rule context="result">

            <sch:let name="pupil" value="name"/>

            <sch:assert role="error" test="not(preceding-sibling::result[name eq $pupil])">We

                already had an result for <sch:value-of select="$pupil"/></sch:assert>

        </sch:rule>

    </sch:pattern>

 

    <sch:pattern>

        <sch:rule context="result[math eq 'A']">

            <sch:let name="pupil" value="name"/>

            <sch:report role="information" test="english = ('A', 'B')">Get in touch with

                    <sch:value-of select="$pupil"/>, maybe he/she will join us</sch:report>

        </sch:rule>

    </sch:pattern>

 

Question is: is this document valid or invalid with respect to the given Schematron schema?

 

<results>

    <result>

        <name>John</name>

        <english>B</english>

        <math>A</math>

    </result>

</results>

 

My answer as the designer of the Language would be „YES of course it is valid, that’s why I marked the second rule as ‘information’“. Since the @role attribute is “A name describing the function of the assertion or context node in the pattern” [ISO/IEC 19757-3 § 5.5.11], the function of the second assertion is to act as an information only.

 

But why not ask a general Schematron validator? I understand that the skeleton reference implementation, when applied to schema given above, generates a validator in XSL. According to [ISO/IEC 19757-3 § 6.1], it should be  a function returning “valid”, “invalid” or “error. However, the XSL Script which is generated by the skeleton implementation generates an SVRL document which does not explicit state that the document is  “valid” or “invalid”. Instead, it contains this element:

 

<svrl:successful-report test="english = ('A', 'B')"

                           role="information"

                           location="/results[1]/result[1]">

      <svrl:text>Get in touch with

                    John, maybe he/she will join us</svrl:text>

   </svrl:successful-report>

 

Does the “successful report” and the “information” level indicate that the document is valid? What if I had used the equivalent <sch:assert test=’not(…)’ /> syntax, which would generate a failed-assert element?

 

I am puzzled. Does the existence of any successful-report or failed-assert element in SVRL indicate that the document is invalid? Or is it my own interpretation of the SVRL Elements together with the @role attribute what the result really means in terms of valid or invalid?

 

Thanks in advance,

Frank Steimke



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]


PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.