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] XML Schema complex type restriction

On 25 September 2017 at 19:50, Michael Kay <mike@saxonica.com> 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:

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

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

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. 



--
Regards,
Mukul Gandhi


[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