Re: [xml-dev] Constraining a Schema

["Imsieke, Gerrit, le-tex" <gerrit.imsieke@le-tex.de>]

Hi John,

As Eric van der Vlist writes, restricting existing schemas that lack 
fine-grained hooks for everything that possibly needs to be constrained 
in the future is harder than extending existing schemas:
http://books.xmlschemata.org/relaxng/relax-CHP-12-SECT-1.html#relax-CHP-12-SECT-1.3

If you don’t want to modify the base schema, Schematron is the 
established way to add an orthogonal layer of additional constraints.

Epischema is another, grammar-based approach, in which you 
simultaneously apply the liberal base schema and a sparse additional 
schema that only imposes the desired restrictions but otherwise permits 
any element or attribute:

https://www.xml.com/articles/2017/04/29/epischemas/
http://archive.xmlprague.cz/2017/files/presentations/epischema/

The examples have been delivered as Relax NG, but it should be possible 
at least in principle to implement them in XSD 1.1 where you can have 
sparse co-occurrence constraints through the new xs:any/@notQName attribute.

The main advantage of epischema over Schematron is better content 
completion that takes into account the additional restrictions – 
provided that the XML editor allows the association of multiple schemas 
and that it only suggests what is legal against all associated schemas 
in a given context. To my knowledge, oXygen XML editor, with the Relax 
NG schemas bundled into a single NVDL schema, is currently the only tool 
that supports this approach.

If constraint-compliant content completion is not an issue, or if XSD is 
the schema language of choice, I suggest an additional Schematron schema 
or programmatically (by means of XSLT) patching the base XSD in order to 
add grammatical constraints and/or xs:asserts.

Gerrit


On 15.08.2018 23:25, John Dziurlaj 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
--
Gerrit Imsieke
Geschäftsführer / Managing Director
le-tex publishing services GmbH
Weissenfelser Str. 84, 04229 Leipzig, Germany
Phone +49 341 355356 110, Fax +49 341 355356 510
gerrit.imsieke@le-tex.de, http://www.le-tex.de

Registergericht / Commercial Register: Amtsgericht Leipzig
Registernummer / Registration Number: HRB 24930

Geschäftsführer / Managing Directors:
Gerrit Imsieke, Svea Jelonek, Thomas Schmidt