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

Re: XML Schema complex type restriction

  • From: Hans-Juergen Rennau <hrennau@yahoo.de>
  • To: Michael Kay <mike@saxonica.com>
  • Date: Mon, 25 Sep 2017 21:47:34 +0000 (UTC)

Re:  XML Schema complex type restriction
I find the idea of parameterized schemas very interesting, it had never occurred to me. But I think it does not scale out for very complex schemas where the burden of having to anticipate all needs of variation could become overwhelming.

Concerning the tiny vocabulary, your scepsis is perhaps based on the assumption that every variant of restriction which is *formally* possible would have to be supported - and yes, that might become overwhelming, too. But in practise - isn't the by far most important form of restriction one of cardinalites - namely, making optional items either absent or mandatory, and constraining potentially multiple items to be single-valued? Add to this a small (and by far not complete) list of further restrictions (e.g. the replacement of simple type uses by uses of a restricted derivative) - and you would probably address 99% of what is desired in most real scenarios?

Your pointing out of the "convolutions" is very important - it makes clear, once and for all, that formal restriction as defined by XSD is far too limited to address real world scenarios of profiling data models reliably. Thank you for that.


Michael Kay <mike@saxonica.com> schrieb am 16:21 Montag, 25.September 2017:


I think there are two main problems with complex type restriction as defined in XSD.

Firstly, you have to describe the restricted content model rather than describing the differences (which means the parts that are retained are described in more than one place.)

Secondly, what I call "deep restriction" gets incredibly convoluted: for example, if you want to restrict all monetary amounts anywhere within an abc:transaction to be in dollars, then you have to define restrictions of all the intermediate types, most of which will be identical to their base type except that some of the child elements are changed to use a restricted type.

Both these problems can be addressed by defining the restrictions using assertions. I think this is how I would normally do it in XSD 1.1. But it's not ideal: if some type has an optional element defined with minOccurs=0 maxOccurs=1, and we want to restrict this in a subtype to be absent, then the ideal syntax would in some way say "the type is the same except that maxOccurs=0" -- which is I think what Hans-Juergen is proposing. I fear though that the "tiny vocabulary" might grow rather larger than is comfortable once you start examining the use cases in detail.

You probably need to distinguish cases where the schema is designed to enable restriction, and cases where it is customized by a third party. In the first case, I think my preferred design would be to define generic parameterized types, using constructs like maxOccurs="$transaction-limit", with values for the parameters being supplied in a concrete realization of the type.

Michael Kay
Saxonica



On 25 Sep 2017, at 13:47, Hans-Juergen Rennau <hrennau@y...> wrote:

"The trouble with restriction is not knowing exactly what the differences are or why."

This is an interesting point. (And I've always avoided restriction of complex types, instinctively.)

Of course it would, in principle, be very easy to specify a restriction step explicitly, using a tiny vocabulary for specifying the removal of optional elements, other cardinality changes and whatever else is needed. Such a "restriction descriptor" might be the input (together with the original schema) for generating the restricted schema, as well as a new from-scratch schema expressing the restrictions. I wonder if there are any proven approaches to this which might be considered good practise? (And how does NIEM treat this question, where restriction of extreme generality should be extremely important?)

With kind regards,
Hans-J├╝rgen


Rick Jelliffe <rjelliffe@a...> schrieb am 10:01 Montag, 25.September 2017:


You are forced to use a started kitchen sink schema because is standard and therefore will make life easier.

However, most of the elements and attributes are things you dont need. And you know the full schema will blow out implementatuon and confuse testing and anyway YAGNI. 

So you will make profile (Subset) of it using restriction and distribute that. 

But then your schema documents may be bloated. It may be simple just have a parallel validation which just check that only wanted element names are used, using any schema language. 

I.e. In allow elements a,b,c,d,e,f,g,... only chill elements a,b,c,d,e,f,g,... can be used. So the big schema states all the rules. The small one excludes unwanted canes, making it really expect. The trouble with restriction is not knowing exactly what the differences are or why.
Rick




Regards
Rick


On 25 Sep 2017 5:27 PM, "Mukul Gandhi" <gandhi.mukul@g...> wrote:
Hello list,
    Can anyone come up with a useful business use case, to use XML Schema complex type restriction?


--
Regards,
Mukul Gandhi







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