XML.orgXML.org
FOCUS AREAS |XML-DEV |XML.org DAILY NEWSLINK |REGISTRY |RESOURCES |ABOUT
OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
RE: [xml-dev] Constraining a Schema

Not quite. The customer wants to constraint the schema in order to produce
documentation to their downstream consumers, so those consumers know what
data to provide. This is all good information, I will share my chosen
approach in the coming weeks.

John

-----Original Message-----
From: Imsieke, Gerrit, le-tex <gerrit.imsieke@le-tex.de>
Sent: Thursday, August 16, 2018 2:30 AM
To: xml-dev@lists.xml.org
Subject: Re: [xml-dev] Constraining a Schema

I was tacitly assuming that your customer needs /context-dependent/
constraints, for example different div/@type attribute values at different
locations of a TEI document.

If you simply want to throw out elements or attributes wholesale, your base
schema probably provides hooks for defining them away or making them illegal
by one of the other means, Schematron, Relax NG include, programmatic
removal of references or programmatic addition of xs:asserts.

Gerrit

On 16.08.2018 08:20, Imsieke, Gerrit, le-tex wrote:
> 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-CH
> P-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

_______________________________________________________________________

XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support
XML implementation and development. To minimize spam in the archives, you
must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
subscribe: xml-dev-subscribe@lists.xml.org List archive:
http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS