[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Constraining a Schema

  • From: Rick Jelliffe <rjelliffe@allette.com.au>
  • To: John Dziurlaj <john@hiltonroscoe.com>
  • Date: Fri, 17 Aug 2018 17:40:12 +1000

Re:  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 <john@hiltonroscoe.com> 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

 




[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!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
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.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.