|
[XML-DEV Mailing List Archive Home]
[By Thread]
[By Date]
[Recent Entries]
[Reply To This Message]
Re: Constraining a Schema
- From: Michael Kay <mike@saxonica.com>
- To: John Dziurlaj <john@hiltonroscoe.com>
- Date: Thu, 16 Aug 2018 14:31:01 +0100
 In my experience deriving complex types by restriction is hopelessly unwieldy. For example, if the original schema allows a set of 20 currencies and you want to restrict this to just 3, then it's easy enough to define a simple type that restricts the set of currencies; but you then need a restricted version of each containing complex type, all the way up to the root node, that uses the restricted type instead of the original. Since restricting a complex type involves restating all the parts that haven't changed, you end up effectively defining a new schema rather than just defining the differences from the original one.
Another approach is to define the new schema by redefining the old one using xs:redefine. That breaks horribly if you ever need to use both schemas simultaneously, e.g. if you are using data binding or if you want to do a schema-aware transformation from one to the other (the reason it breaks is that you now have several types with the same name in your system). The new xs:override in XSD 1.1 does nothing to solve this problem.
Another approach is schema transformation: define the new schema as the result of applying an XSLT transformation to the old one (is this your option (1)?). This still leaves you the problem of having multiple declarations with the same name in the system (you can rename the types into a different namespace, but you can't rename the element declarations).
My own preference is to restrict at the top level using assertions, but as you say, this requires XSD 1.1. If that's a problem then adding a schematron layer may work better for you.
Michael Kay Saxonica
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:
- Subset schema using available XML tooling. A standalone derivative will be produced.
- Create a new schema, referencing the old one, but derive all the types by restriction.
- Use XML Assertions
- Use Schematron
- 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
|
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
|
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format
| RSS 2.0 |
 |
| Atom 0.3 |
 |
| |
Stylus Studio has published XML-DEV in RSS and ATOM formats,
enabling users to easily subcribe to the list from their preferred news reader application.
|
Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website.
they were not included by the author in the initial post. To view the content without the Sponsor Links please
click here.
|
|
Cart
