Visual Basic 2012 Voorbeelden
   

visual basic 2012 broncode voorbeelden

Blijf op de hoogte van de recente aanpassingen op vbvoorbeelden!

Microsoft Visual Studio 2012Microsoft Developers Network - Visual BasicMicrosoft .NET Framework

30.3. XSD Type Definities - Kardinaliteit

Print Email Deel op Twitter Deel op Facebook

Dit artikel is gepubliceerd op maandag 15 oktober 2012 op vbvoorbeelden, bezoek de website voor een recente versie van dit artikel of andere artikels.

30.3.1. Kardinaliteit van Elementen

Bepalen 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>

30.3.2. Kardinaliteit van Attributen

Een 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 maandag 15 oktober 2012 op vbvoorbeelden, bezoek de website voor een recente versie van dit artikel of andere artikels.