Cart
[Home] [By Thread] [By Date] [Recent Entries]
Costello, Roger L. said: > Hi Folks, > > I am putting together a list of ways that Schematron is being used. I > seek your help in ensuring that the list is complete. (I will post the > final list) Perhaps existence may be considered a special case of cardinality: count() is very common in Schematron schemas for cardinality. And does "existence" capture the position-independence aspect? Similarly, where does guarantees of uniqueness fit in? (e.g. count(//x[@id=current()/@id) = 1 ) I don't think they are co-constraints or existence. But people do key/id checking. Also, some papers subdivide co-constraints to differentiate value and structure: value-value value-structure structure-value value-value but the reality seems more complicated. Murata-san's 2005 paper http://www2005.org/keynotes/makoto.pdf at slide 35 identifies some uses for the Japanese Local Government project. He identifies identity constraints such as //a/b + //c/d = //e/f plus inter-document checks as being key. The trouble with the terms "co-constraint" or "co-occurrence constraint" is that they suggest that there are only two terms, whereas there can be multiple terms. In BR's enormous Danish example earlier, shocked readers will be relieved to know that ISO Schematron allows variables, so that expression could be factored into smaller named chunks for clarity. However, equations are often important. I expect that the use of Schematron to test formulae or equations will increase with the advent of EXLST and XSLT2-based implementions under current testing. For example, to check that the total fields match the sum of the entries, to some level of precision at least. In the ACORD (London Markets) work, it is used as for gatekeeping: http://www.lloyds.com/News_Centre/Features_from_Lloyds/Schematron_pushes_the_right_buttons.htm There is some detail of where they use Schematron and where they use XSD at http://www.marketreform.co.uk/Documents/Claims_pubs/London_Market_Implementation_of_ACORD_DRI_Messages.pdf around page 34: * Inconsistency between fields of this message * The message refers to a supporting message and it was not received * Cross field validation found missing data (co-occurrence and existance!) The diagram on page 39 makes their process flow clearer. A really interesting document is http://www.eurocontrol.int/eaip/gallery/content/public/doc/pdf/book_eAIPSpecification.pdf This gives the publication rules for Air Traffic Control manuals for a large chunk of Europe. The fun starts around page 12 (18) s3.3.2 Additional Rules. These gives rules such as "Route segments in the same route may not have mixed true track and magnetic track." It seems that they allow segments to be marked "deleted", therefore there are constraints to apply to "the first non-deleted segment..." Is that a co-constraint? The Eurocontrol document also mentions checking against MIME types: so add enumeration checking to the list. Also link and reference checking. Also simple data typing (value of attribute must be positive number). They also have mandatory and optional rules. (I don't know if they implement them as separate Schematron phases or separate schemas.) Cheers Rick Jelliffe
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
