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

Re: XML Schema complex type restriction

  • From: Rick Jelliffe <rjelliffe@allette.com.au>
  • To: Mukul Gandhi <gandhi.mukul@gmail.com>, "xml-dev@l..." <xml-dev@l...>
  • Date: Fri, 29 Sep 2017 01:37:32 +1000

Re:  XML Schema complex type restriction
I think assertions are always subsumptive in your terminology.  Even if they appear to allow otherwise.

For example, if you have an element of type Integer and the assertion constrains the element to be either the text "54" or the number 32, the type is constrained to be the number 32.  The constraint of having text "54" would never be exercised.

This is because an assertion is essentially ANDed with the grammar or datatype or keyref etc constraints. Like a Bloom filter.


On Thu, Sep 28, 2017 at 10:37 PM, Mukul Gandhi <gandhi.mukul@gmail.com> wrote:
On 25 September 2017 at 19:50, Michael Kay <mike@s...> wrote:
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.

Here's the syntax of complex type restrictions as specified by XSD 1.1 spec:

  id = ID
  mixed = boolean
  {any attributes with non-schema namespace . . .}>
  Content: (annotation?, (restriction | extension))

  base = QName
  id = ID
  {any attributes with non-schema namespace . . .}>
  Content: (annotation?, openContent?, (group | all | choice | sequence)?, ((attribute | attributeGroup)*, anyAttribute?), assert*)

The notion of this restriction concept, excluding the effect of <assert> is essentially same as defined in XSD 1.0. 
Although XSD 1.1 introduces new prose in this respect. In a nutshell, the complex type <restriction> defines that content model inside it
is subsumptive (i.e it has fewer options) of the base type's content model. But the use of <assert> here can choose to violate or
not violate this subsumptive notion. Therefore, using <assert> is a double edged sword at this place. May be the XSD 1.1 spec, could
have chosen to explain this behavior of <assert> in complex type restrictions. As of now, I cannot find this explanation in XSD 1.1 spec. 

Mukul Gandhi

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


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.
First Name
Last Name
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.