|
Dit artikel is gepubliceerd op zondag 31 juli 2011 op vbvoorbeelden, bezoek de website voor een recente versie van dit artikel of andere artikels.
29.3.1. Kardinaliteit van ElementenBepalen hoe vaak een element kan voorkomen kan via de minOccurs en maxOccurs attributen in <xsd:element> node, bijvoorbeeld : XML Schema Definition <?xml version="1.0" encoding="utf-8"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:element type="article" name="article"/>
<xsd:complexType name="article">
<xsd:sequence>
<xsd:element name="name" type="xsd:string" minOccurs="1" maxOccurs="unbounded" />
</xsd:sequence>
<xsd:attribute name="price" type="xsd:decimal" />
</xsd:complexType>
</xsd:schema>De attributen minOccurs="1" maxOccurs="unbounded" maken het mogelijk één of meerdere <name> childnodes toe te voegen aan de <article> nodes.
Volgende XML documenten zijn conform dit schema : XML Instantie <?xml version="1.0" encoding="utf-8" ?>
<article price="9.99">
<name>Hat</name>
<name>Bonnet</name>
<name>Chapeau</name>
</article> XML Instantie <?xml version="1.0" encoding="utf-8" ?>
<article price="9.99">
<name>Hat</name>
</article> Het artikel kan hier dus één of meerdere namen hebben.
Mogelijke waardes voor de attributen minOccurs en maxOccurs zijn positieve gehele getallen of "unbounded" voor maxOccurs, by default staan deze attributen op "1" en is het element dus verplicht.
Bij globale elementen kan men deze attributen niet gebruiken, want deze occurrency constraints gelden ten aanzien van een container element.
Volgens volgend schema bijvoorbeeld moet er immers steeds één rootelement employee aanwezig zijn : XML Schema Definition <?xml version="1.0" encoding="utf-8"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:element name="employee" type="xsd:string" />
</xsd:schema> Volgend XML document, zonder employee node zou niet valideren naar dit (of eender welk ander) schema : XML Instantie <?xml version="1.0" encoding="utf-8"?> Wat wel conform dit schema is, is elke XML document met exact één rootelement employee : XML Instantie <?xml version="1.0" encoding="utf-8"?>
<employee>John</employee>  boven
29.3.2. Kardinaliteit van AttributenEen attribuut mag altijd maximaal één keer voorkomen, men kan wel bepalen of een attribuut optioneel is ( "optional" ), verplicht is ( "required" ), of zelfs verboden is ( "prohibited" ) via het use attribuut van een <xsd:attribute> node.
Optioneel is de default, waardoor men niet verplicht is volgens volgend schema om in een <employee> node een name attribuut te voorzien : XML Schema Definition <?xml version="1.0" encoding="utf-8"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:element name="employee">
<xsd:complexType>
<xsd:attribute name="name" type="xsd:string" />
</xsd:complexType>
</xsd:element>
</xsd:schema>Beide ( zowel die met name attribuut als die zonder ) van volgende XML documenten zijn conform dit schema : XML Instantie <?xml version="1.0" encoding="utf-8"?>
<employee name="John" /> XML Instantie <?xml version="1.0" encoding="utf-8"?>
<employee /> Om hier de aanwezigheid van het name attribuut te verplichten kunnen we in het schema aan de <xsd:attribute> node het attribuut use="required" toevoegen : XML Schema Definition <?xml version="1.0" encoding="utf-8"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:element name="employee">
<xsd:complexType>
<xsd:attribute name="name" type="xsd:string" use="required" />
</xsd:complexType>
</xsd:element>
</xsd:schema>Van de hiervoor vermelde XML documenten zal nu enkel de eerste correct valideren volgens dit aangepaste schema.
De waarde "prohibited" dient enkel om expliciet aan te geven dat een bepaald attribuut niet ( meer ) mag voorkomen. Dit is eigenlijk ook zo als dit attribuut niet meer in het schema is opgenomen.
Zo zal volgend XML document niet valideren naar het laatste schema : XML Instantie <?xml version="1.0" encoding="utf-8"?>
<employee name="John" ID="15" /> Attribuut ID was immers niet opgenomen in het schema.
Wenst men toch mogelijks een ID attribuut te kunnen opnemen, dan kunnen we het schema als volgt aanpassen : XML Schema Definition <?xml version="1.0" encoding="utf-8"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:element name="employee">
<xsd:complexType>
<xsd:attribute name="name" type="xsd:string" use="required" />
<xsd:attribute name="ID" type="xsd:string" use="optional" />
</xsd:complexType>
</xsd:element>
</xsd:schema>Het laatste vermelde XML document is nu wel conform dit schema.
Volgens het schema mogen de employee elementen hier geen data bevatten. Er is hier immers geen "content model" opgegeven in de typedefinitie van employee, er staan bijvoorbeeld geen <xsd:element> nodes in.
Dit is wat men noemt een restrictive complexContent complexType.
Bemerk dat we dit schema, om hetzelfde data model te vormen, ook als volgt kunnen definiëren : XML Schema Definition <?xml version="1.0" encoding="utf-8"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:element name="employee">
<xsd:complexType>
<xsd:complexContent>
<xsd:restriction base="xsd:anyType">
<xsd:attribute name="name" type="xsd:string" use="required" />
<xsd:attribute name="ID" type="xsd:decimal" use="optional" />
</xsd:restriction>
</xsd:complexContent>
</xsd:complexType>
</xsd:element>
</xsd:schema>Als in een schema voor een complexType element geen content type ( simpleContent of complexContent ) is opgegeven, is dit by default een complexContent met een restriction van xsd:anyType.
Verderop meer informatie over xsd:anyType, simpleContent, complexContent, simpleType en complexType.
Het is duidelijk dat het eerste schema voor dit data model veel eenvoudiger en leesbaarder is.
Dit artikel is gepubliceerd op zondag 31 juli 2011 op vbvoorbeelden, bezoek de website voor een recente versie van dit artikel of andere artikels.
| hoofdstuk |
 28. 29. 30.  |
| onderwerp |
29.2. 29.3. XSD Type Definities - Kardinaliteit 29.4. |
| broncode |
|
| datum |
laatst gewijzigd op maandag 29 maart 2010, laatst gepubliceerd op zondag 31 juli 2011 |
| 
