XML.orgXML.org
FOCUS AREAS |XML-DEV |XML.org DAILY NEWSLINK |REGISTRY |RESOURCES |ABOUT
OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] ANN: 10 Laws of Schematron Design

I think you are trying to make Schematron look like CAM or xsd 1.1.  That is fine for some uses.

But essentially it says the concepts and mechanisms of the pattern, rule and phase are not useful. I think they are useful, and so I think these laws are a retrograde step, if i have understood them.

Consider a table: it is a classic "pattern": a grouping of multiple constraints between multiple nodes.  Tables have rows, rows have cells, cells belong to columns, columns have colspecs, etc.  In your Laws there is no way to represent a table: a pattern can only have one rule and a rule can only have one assertion. So you are only left with disconnected assertions. And no patterns, therefore no phases.

And with only a single assertion per rule, there is no way to collect or divide related assertions. So you have individual facets without the diamond; wood but no trees.  

And no room for case statements: factoring out special cases to dedicated rules within a pattern so that the general case can be expressed simply. And no room for default rules, to cope with the fallthrough case.

Perhaps identifying the situations where your laws are appropriate might be good.  I understand the point about traceability, but i dont think i agree with it.

Cheers
Rick



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


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS