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
, 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
