Data Management Blog: How I learned to love @OASISopen CAM

 

Data Management Blog
Data management, Cloud, Transformation and anything else...









How I learned to love @OASISopen CAM

I've played around with @OASISopen CAM in the past, but mostly from a learning and experimentation perspective.  I thought it an interesting technology and always wanted to find a reason to use it in real life.  But for some time that opportunity wasn't at hand. 

The most powerful aspect of this is to allow data model and constraints to travel and live together. 

Schematron, (xml schema 1.1), and xslt

The problem:
We were working with industry standards in terms of xml schema data models.  These were the starting point.  There was a need to add on additional constraints.  But within the standard (i.e. co-occurence constraints which can't be put in xml schema) or outside the standard where busiensses take the standard and build their own additional constraints onto it as a base. 

Schematron to the rescue?
The most logical technology to use at the time was of course schematron (and still is of course).  The problem I was trying to solve was that schematron was understood by xml geeks like myself.  However, the people who knew the business rules were speaking an entirely different language.  So the only choices either to have the xml geeks be the translator or to create a translation tool for business people to use.  In one sense I was doing both.  I created an interface to simplified schematron specifically for business analysts.  By creating a simple interface, then business people could input simple rules without a problem.  No middle man.  But any more complex rules could only be roughed in and the xml geek would then need to step in and translate the business rules into schematron patters.

The interface started out as absolute simplicity.  It was "if ... then" at its core.  If this business condition exists, then some other rule applies.  At it's simplest, 2 element names were the minimum point needed.  And it was put in a simple HTML web form, an interface BAs were very familiar with.  The web form would take the input and generate the schematron assertions as well as use the schematron skeleton template to create an XSLT that would validate xml with these assertions.  At that time the skeleton was used widely because no ANT task or native schematron processor was in place.

The simplicity of this approach was both its biggest strength and of course also its biggest weakness.  Only a rudimentary knowledge of xml and a business analyst could create schmatron compliant rules by simply identifying 2 components of this "if ... then" assertion.  Scmeatron and XSLT validator came out the other end automagically.  But of course complex assertions defied this method and so the xml expert had to intervene and help the BA formulate the rules. 

This worked for its limited aims.  But we still had the problem of separate technologies for validation.  It would be best to have schematron embedded directly into the schema.  Indeed this is what eventually what xml schema 1.1 would enable.

Enter @OASISopen CAM
Working with CAM on a consulting gig moved me from seeing it not just as an interesting technology to one that I like.  One big benefit is that all validation rules can be put in one place.  Content model, data typing, co-occurence, or any other constraint could travel together.

Secondly, there was a CAM processor that provided a relatively easy to use interface to creating assertions.  Not quite as simple as my earlier effort, but also not as limiting as it was as well.  So business analysts can do some of the work in creating assertions, although xml knowledge is of course essential. 

While I'm still working with it and learning its warts, I've come to appreciate CAM.  And of course one can't mention CAM without a shout out to David Webber.




© Copyright Paul Kiel.