Re: [xml-dev] Constraining a Schema

One method that might be easier to sell to people from a database background is to not talk in terms of schemas at all, even though you utilize them.

So you have 1) a Data Dictionary  (or vocabulary) and 2) Business Rules for the server and for each client (if they need it).

For the Data Dictionary, you have a XSD which models vocabulary, datatype and containment only. minOccurs = 0 and maxOccurs=unbounded for everything.  No use of xsd:sequence, everything is a choice.

For the Business Rules, you have your particular schemas for the server and each client, which includes sequence and occurrence.  You could of course maintain an intermediate schema which you customize to make the Business rules (probably the same as the server's schema) but that is your internal choice.

An advantage of this method is that you get the groups of stakeholders involved in the Data Dictionary effort, but more 1-1 negotiation on the particular Business Rules. This prevents the horrible and common problem where committees of stakeholders get fixated on structures and minutae and favour their particular use case: they will merely repeat structures they have seen before which is often limited experience. And the situation where developers are disenfanchised on discussion of the easiest point-to-point language (e.g. a client developer cannot ask "please use this convention for your IDs" because the big schema has decided on some universal convention that is not appropriate, or some elements are required that are not relevant to the particular client.)

So this kind of approach depends on the organizational issue at play, more than technical.  You completely pin down only the very minimum that coincides with what everyone needs with (name, containment, base datatype) with total generosity, but you punt on the issues of occurrence and position so that they can be negotiations multilaterally.

Regards

Rick

On Thu, Aug 16, 2018 at 7:25 AM, John Dziurlaj <[email protected]> wrote:

I am working with a schema that is purposely lax (i.e. it may allow too many occurrences, may contain irrelevant elements, etc.) so that it can handle a broad range of customer scenarios. I now have a customer that wants to constrain the schema such that only a subset of the functionality is available. This subset is expected to validate against its larger parent. I’ve come up with a number of different approaches to handle this:

 

1. Subset schema using available XML tooling. A standalone derivative will be produced.
2. Create a new schema, referencing the old one, but derive all the types by restriction.
3. Use XML Assertions
4. Use Schematron
5. Use CAMV

 

My preference is to use a XML Schema native approach (1-3), using XSD 1.0 only constructs if possible (1-2), as the actual used XML processor that gets used is outside my control.

 

Does anyone have ideas on a good approach?

 

John Dziurlaj

 

Elections Consultant

Hilton Roscoe LLC
Cell 330-714-8935 Work/Fax 234-706-6434