Embbeding Validation Rules into XML Schema

[mgratacos]

Validation rules provide additional data constrains which cannot be expressed using W3C XML Schema. An example of a validation rule for a derivative trade is “Effective date must be after the trade date”. You cannot enforce that using Schema. One of the problems that I usually find in XML vocabularies (FpML is a good example) is that validation rules and the actual Schema are not tied together. I mean, implementers use the schema but sometimes they don’t use the addional validation rules. Sometimes they are not aware of them. These rules, as the example mentioned above, can be implemented using constraint rule languages such as Schematron, XQuery, CLiX, XPath, or other languages. Even though sometimes they are seen as a secondary component, they have an important role to ensure proper data validation. One of the options to bring both schema and validation rules together is to embed the validation rules into the actual schema grammar. There is an interesting article from Roger Costello available [url=http://www.xfront.com/ExtendingSchemas.html]here[/url]. It shows examples of how to do that using for example, Schematron. There is another interesting article describing the same idea using XQuery available [url=http://www.idealliance.org/papers/dx_xmle03/papers/03-02-03/03-02-03.pdf#search=xpath%202%20schematron]here[/url] (pdf). For a vocabulary such as FpML, the cost of doing this is that you have to choose a specific rule language for implementing the rules (i.e. XQuery, Schematron,…). On the other hand, I think the benefits are: * The awarness of the existence of the validation rules increases since the schema and the validation rules are written and released together. * It’s easier for users to implement the rules since at least they have a free implementation of the rules available. * Synchronizing the set of rules and schema is “easier” – I mean, if the two components are written in the same place, it’s easier to detect if a rule is affected by a schema change and the other way around. In conclusion, I think it’s an interesting idea to consider.

[prashant]

To me collocating contraint rules along w/ Schema makes me feel that we loose the clean seperation & notion of rules engine & rules provisioning. We currently have a notion of –Rules Engine that manage provisioned rules and rules could be written in more than one language–depending on complexity of rule(s). Also, as noted even the articles above, not all constraints will be suitable/expressable in one constraint language. If collocation of rules has to been done then I am guessing that FpML Specs designers would have to covert the rules as currently specified in “english” into a choosen contrainst langauge(s). This means they will have to make a reference choice—and when more rules have to be added or removed then it will look like end-users changing the specs as provided by FpML body—all of this means more maintaince head-ache. My 2 cents Prashant Sarode 🙂

[matthew]

Colocating method rules and assertions inside classes works well in mainstream OO languages. What is different here?

[andrew]

The current separation of the schema and the business rules allows implementors to both be selective in the rules they choose to adopt in thier service. Both Markit Wire and the DTCC implement a selection of standard FpML business rules and some of their own devising to validate that trades match the requirements of thier service. If the rules where embedded within the schema they would not have this flexability to mix and match rules to suit thier business needs. It’s also unclear how embedded rules would work in environments where banks have used FpML as the basis of an extended grammar for internal messaging. A strictly implemented constraint in the FpML grammar could prevent users from extending a definition as they can today. There are some rules that are so basic that it might be possible to get agreement for including them in the schema but that would leave a number of more complex rules that would still need to be checked post XML validation as they are today, and whatever technology you choose to build this in could equally well be used to the check the simple rules as well. Why validate using two different techniques when one will do everything? Constraints in schema is an interesting academic exercise but I’m personally not convinced that it will gain much practical implementation.

[Author]

Posts