additional constraints validation variant

Greetings folks,

I have been working with the schematron "adding additional constraints" issues that are most accurately addressed in the OAGIS8.0 design.  This design solves the problem quite well of the desire for a single general model that is constrained by context.  Nice job folks!  (For example, in one of our cases having a general HR-XML TimeCard with contextual variations such as "DeleteTimeCard", "CreateTimeCard", "UpdateTimeCard" etc.)

The use of schematron here is perfect.  I would like to add a wrinkle for perhaps a variant to this approach.  The links below illustrate two methods of achieving the same goals, both using schematron to document constraints.  However where these constraints are applied differs.  

The first link, "InstanceValidationFlow", shows how one may use a document (in this case an HR-XML TimeCard) in a validation flow.  The two step approach (parser plus xslt) works well.  

http://ns.hr-xml.org/temp/InstanceValidationFlow.gif

The second link, XSDValidationFlow", shows a flow where validation occurs via a derivation of the schema itself instead of the instance in a second step.  This would maintain the goal of general model with context-specific constraints but without a second step validation (which is where I get the push back from my constituents who otherwise like the use of schematron).

http://ns.hr-xml.org/temp/XSDValidationFlow.gif

What do you think of this approach?  I haven't decided if I like it yet, but I thought enough of it to merit a thread here.  

The development of a Constraints2XSD stylesheet would not be simple, but I would think doable - and reusable!  [I talked with Mark Feblowitz about this once and he was, I believe, intrigued by it -- Mark, is that the case??]  Might anyone out there be interested in collaboratively creating such an animal?

Pluses and Minuses:
Method 1 - InstanceValidationFlow
+ transforming constraints to validating xslt easily replicated (i.e. via schematron skeleton xsl)
- results in many xslts laying around for validation (one for each context)
- requires another validation layer via XSLT (performance)


Method 2 - XSDValidationFlow
+ single validation layer
+ makes most use of parser
- results in many schemas laying around for validation (one for each context)
- xslt for transformation of constraints to xsd not developed (yet!?!)
 



W. Paul Kiel
HR-XML Consortium