Attribute, Entities und Komplexe Elementtyp-Deklaration

Inhaltsangabe:

  1. Attributdeklaration
  2. Entities
  3. Komplexe Elementtyp-Deklaration
  4. Namensräume und Kommentare

Attributdeklaration

Grundsätzlich:

<! ATTLIST Element_Name
Attribut_Name Datentyp Vorgabewert
Attribut_Name Datentyp Vorgabewert
...
>

Datentypen:

    • CDATA
      Alle Zeichen sind erlaubt, außer: <, “ und &
      * Kontrolle der Werte 
           <! ATTLIST anrede
bez (Firma|Frau|Herr) "Frau"
titel CDATA #IMPLIED >
    • ID
      zur eindeutigen Identifikation eines Elementes: 
      <! ATTLIST Dreieck
identifier ID #REQUIRED
S_A CDATA "12cm"
S_B CDATA "10cm"
S_C CDATA "8cm"
>

Wenn anstelle eines Einzelwertes eine Liste von möglichen Werten angegeben werden soll, müssen die jeweiligen Pluralformen verwendet werden.

    • IDREF / IDREFS
      In Verbindung mit dem Attribut ID kann mit diesen Attributtypen eine Verbindung zwischen Elementen geschaffen werden.
    • ENTITY / ENTITIES
      …siehe eigenen Sitzungspunkt…
    • NMTOKEN /NMTOKENS
      Daten müssen mit einem Buchstaben oder einem Unterstrich beginnen und dürfen kein Leerzeichen oder Doppelpunkt enthalten. Ebenfalls untersagt sind Werte, die mit xml oder XML beginnen.
    • NOTATION
      Notwendig zur Einbindung von „Nicht XML Daten“ in eine XML-Dokument.
      Der Wert des Attributes ist der Name der einer Notation, die mit <!NOTATION> in der DTD deklariert wurde.

Vorgabewert:

<! ATTLIST Dreieck
S_A CDATA "12cm"
S_B CDATA "10cm"
S_C CDATA "8cm"
>
  • #REQUIRED 
    <! ATTLIST Dreieck
S_A CDATA #REQUIRED
S_B CDATA #REQUIRED
S_C CDATA #REQUIRED
Farbe CDATA #REQUIRED
>
  • #IMPLIED 
    <! ATTLIST Dreieck
S_A CDATA #REQUIRED
S_B CDATA #REQUIRED
S_C CDATA #REQUIRED
Farbe CDATA #IMPLIED
>
  • #FIXED 
    <! ATTLIST Dreieck
S_A CDATA #FIXED "10cm"
S_B CDATA #REQUIRED
S_C CDATA #REQUIRED
Farbe CDATA #IMPLIED
>

Entities

Parameter-Entities

Um das Schreiben komplexerer DTDs zu erleichtern, besteht die Möglichkeit zur Definition von Parameter Entities. Diese werden mit der <!ENTITY … > Definition ermöglicht. Entity Definitionen weisen einem Namen eine Zeichenkette als Wert zu.

Mit Parameter-Entities werden also benannte „Abkürzungen“ in der DTD definiert, die referenziert werden können, um mehrfach vorkommende Elementgruppen und Attributlisten jeweils nur einmal definieren zu müssen:

Deklaration allgemein

<!ENTITY % entity_name "(content model)|Ersetzungstext">

Referenzierung allgemein

<!ELEMENT element_name %entity_name;>

Beispiel

Deklaration:

<!ENTITY % katalogdaten"(kuenstler+, titel, untertitel?, jahr, id)">
<!ENTITY % id "id ID #REQUIRED">

Referenzierung:

<!ELEMENT skulptur %katalogdaten;>
<!ELEMENT bild %katalogdaten;>
<!ELEMENT foto %katalogdaten;>
<!ATTLIST kurs %id;>
<!ATTLIST referent %id;>

Weitere Entities

  • externe Entities
  • interne Entities
  • externe Parameter-Entities
  • nicht analysierte Entities = Notations

Beispiele:

Geschäftsbrief

DTD

      <!-- DTD document brief.xml  -->

	<!ELEMENT brief (kontaktart*, anrede, absatz+, url,
	   schlussformel, unterschrift )>
	<!ELEMENT kontaktart (sender, empfaenger, zusatz*)>
	<!ENTITY % kontaktdaten "(name, addresse+, ort, plz, telefon*)">
	<!ELEMENT sender %kontaktdaten;>
	<!ELEMENT empfaenger %kontaktdaten;>
	<!ELEMENT zusatz %kontaktdaten;>
	
	<!ELEMENT name ( #PCDATA )>
	<!ELEMENT addresse ( strasse, hausnummer )>
	<!ELEMENT ort ( #PCDATA )>
	<!ELEMENT plz ( #PCDATA )>
	<!ELEMENT telefon ( #PCDATA )>
	
	<!ELEMENT strasse ( #PCDATA )>
	<!ELEMENT hausnummer ( #PCDATA ) >
	 
	<!ELEMENT anrede ( #PCDATA )>
	<!ELEMENT schlussformel ( #PCDATA )>
	<!ELEMENT absatz ( #PCDATA )>
        <!ELEMENT url (#PCDATA)>
	<!ELEMENT unterschrift ( #PCDATA )>

XML

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE brief SYSTEM "brief.dtd">

<brief>
    
    <kontaktart>
        <sender>
            <name>SoundSo GMBH</name>
            <addresse>
                <strasse>Soundsostr.</strasse>
                <hausnummer>1</hausnummer>
            </addresse>   
            <ort>Soundsostadt</ort>
            <plz>12345</plz>
            <telefon>+499 711 48 68 69</telefon>
        </sender>
        <empfaenger>
            <name>Sowieso</name>
            <addresse>
                <strasse>Sowiesostr.</strasse>
                <hausnummer>2</hausnummer>
            </addresse>
            <ort>Sowiesostadt</ort>
            <plz>54321</plz>
            <telefon>0842 2457158</telefon>
        </empfaenger>
        <zusatz>
            <name>ABC Amtsgericht</name>
            <addresse>
                <strasse>Musterstr.</strasse>
                <hausnummer>1</hausnummer>
            </addresse>
            <ort>Musterstadt</ort>
            <plz>9876</plz>
        </zusatz>
    </kontaktart>
    
    <anrede>Sehr geehrter,</anrede>
    
    <absatz>Wir freuen Ihnen mitteilen zu dürfen, 
        dass Sie ein Upgrade für Ihren Flug nach Timbuktu...
    </absatz>
    
    <absatz>(...)
    </absatz>
    <url>http://firstclasssowieso.de</url>
    <schlussformel>Mit freundlichen Grüßen,</schlussformel>
    <unterschrift>Sarah Soundso</unterschrift>
    
</brief>

Kunstsammlung

DTD

<!-- DTD document kunstsammlung.xml  -->
 <!ELEMENT kunstsammlung (name?, lokalisation, gemaelde*, video*, foto*, skulptur*)> 
<!ELEMENT name (#PCDATA)>
<!ELEMENT lokalisation EMPTY>
<!ATTLIST lokalisation
            url CDATA #IMPLIED
       postal CDATA #IMPLIED>

<!ENTITY % info "(katalog, inhalt)">
<!ELEMENT gemaelde %info;>
<!ELEMENT video %info;>
<!ELEMENT foto %info;>
<!ELEMENT skulptur %info;>
<!ELEMENT katalog (titel, url, abstract*, kuenstler)>
<!ELEMENT titel (#PCDATA)>
<!ELEMENT url (#PCDATA)>
<!ELEMENT abstract (#PCDATA)>
<!ELEMENT kuenstler (#PCDATA) >
<!ELEMENT inhalt (person*, bauwerk*, andere*)>
<!ELEMENT person (bezeichnung+)>
<!ELEMENT bauwerk (bezeichnung+)>
<!ELEMENT andere (bezeichnung+)>
<!ELEMENT bezeichnung (#PCDATA)>

XML

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE kunstsammlung SYSTEM "kunstsammlung.dtd">
<kunstsammlung>
    
    <name>Neue schöne Bilder</name>
    
    <lokalisation url="http://www.bilder.de/"/>
        
        <gemaelde>
            <katalog>
                <titel>Mona Lisa vor dem Eiffelturm</titel>
                <url>http://www.woauchimmer.de</url>
                <kuenstler>Leonarda da Vinci</kuenstler>
            </katalog>
            <inhalt>
                <person>
                    <bezeichnung>Mona Lisa</bezeichnung>
                </person>
                <bauwerk>
                    <bezeichnung>Eiffelturm</bezeichnung>
                </bauwerk>
            </inhalt>
        </gemaelde>
        
        <gemaelde>
            <katalog>
                <titel>Ritter, Burgen, Adel</titel>
                <url>http://www.beispielseite.de</url>
                <kuenstler>Ai Wei Wei</kuenstler>
            </katalog>
            <inhalt>
                <person>
                    <bezeichnung>byzantinische Kaiserin</bezeichnung>
                </person>
                <person>
                    <bezeichnung>Ritter des 13.Jhd</bezeichnung>
                </person>
                <person>
                    <bezeichnung>fränkischer Edelmann</bezeichnung>
                </person>
                <bauwerk>
                    <bezeichnung>Wasserburg</bezeichnung>
                </bauwerk>
            </inhalt>
        </gemaelde>
    
        <skulptur>
           (...)
        </skulptur>
    
        <video>
           (...)
        </video>
    
</kunstsammlung>

Komplexe Elementtyp-Deklaration

Erweiterte Content Model- Deklaration

Um eine bewusste Auswahl zwischen zwei oder mehreren nichtterminalen Elementen in der Content Model- Deklaration zu geben, nutzt man den „logischen Oder Operator“ |. Dadurch kann jeweils nur ein nichtterminales Unterelement in dem übergeordneten Element enthalten sein. Der Inhalt eines Elements mit dem Content Model (A|B) muß demnach dem Content Model A oder dem Content Model B entsprechen:

DTD

<!ELEMENT kosten (warmiete | kaltmiete)>

XML

<kosten>
<warmiete>...</warmiete>
</kosten>
oder

<kosten>
<kaltmiete>...</kaltmiete>
</kosten>

Die Auswahl zwischen zwei oder mehreren Elementen innerhalb der Content Model- Deklaration kann zusätzlich durch Klammern umschlossen werden, sodass einzelne Model Groups entstehen, die eine jeweilige Ausprägung des Content Models definieren:

DTD

<!ELEMENT adresse (email | (strasse, plz, ort))>

XML

<adresse>
<email>...</email>
</adresse>
oder

<adresse>
<strasse>...</strasse>
<plz>...</plz>
<ort>...</ort>
</adresse>

Dadurch können weitaus komplexere Content Models erstellt werden:

DTD

<!ELEMENT e ((v|(x,y)|(p*,z)), (w|(x?,t)|(y?,u)), r)>

XML

<e>
<p>...</p>
<p>...</p>
<p>...</p>
<z>...</z>
<t>...</t>
<r>...</r>
</e>

Mixed Content

Bei Content Model- Deklarationen muss nicht immer strigent zwischen Nichtterminalen und Terminalsymbolen (wie PCDATA) entschieden werden. In der bisherigen Notation wurden beide immer getrennt behandelt.

Ausgangstext

3 cl Tequila

DTD

<!ELEMENT zutat (zutatsname , menge , einheit)>
<!ELEMENT zutatsname (#PCDATA)>
<!ELEMENT menge (#PCDATA)>
<!ELEMENT einheit (#PCDATA)>

XML

<zutat>
<zutatsname>Tequila</zutatsname>
<menge>3</menge>
<einheit>cl</einheit>
</zutat>

Um Redundanzen innerhalb der Strukturen vorzubeugen ist eine Vermischung beider Elemente durch den Mixed Content möglich. Der Mixed Content kann Terminalsymbole mit Nichtterminalen verknüpfen und somit beide Typen gleichzeitig innerhalb eines Elementes ermöglichen.

DTD

<!ELEMENT zutat (#PCDATA | menge | einheit)*>
<!ELEMENT menge (#PCDATA)>
<!ELEMENT einheit (#PCDATA)>

XML

<zutat>Tequila <menge>3</menge> <einheit>cl</einheit></zutat>

Das Terminal #PCDATA darf ausschließlich als erstes Symbol in einer Auswahl mit beliebig vielen weiteren Nichtterminalen verwendet werden. Dem Modell muß schließlich der Häufigkeitsoperator * hinzugefügt werden, um die wiederholte Einbindung von Elementen des aufgeführten Typs bzw. der Textdaten zu ermöglichen.

Namensräume und Kommentare

Namensräume

Das Konzept der Namensräume oder namespaces ist für XML genauso wichtig wie einfach. Es ist notwendig, um Konflikte in der Benennung von Elementen zu umgehen, die ungewollt und schnell auftreten können, da Elementnamen eindeutig sein müssen.

Zum Beispiel kann für eine Bildersammlung das Kind-Element <name> und für das einzelne Bild das Kind-Element <titel> gewählt, um in keinen Namenskonflikt durch die zweimalige Verwendung von Titel zu kommen, da ja sowohl die Sammlung wie auch das einzelne Bild einen Namen aufweist. Aber nur selten lässt sich das Problem auf diese Art elegant lösen.

Namenskonflikte entstehen vermehrt auch dann, wenn verschiedene XML-Anwendungen zusammengeführt werden. Gleichnamige Element können in unterschiedlichen Kontexten eine völlig andersartige Bedeutung haben:

Kontext HTML:

<body> Das ist meine Webseite </body>

Kontext HUMAN:

<body>
<height>182 cm</height>
<weight>85 kg</weight>
</body>

Um den Kontext für ein Element festzulegen, wird vor den Elementnamen ein kontextspezifisches Präfix und als Trennzeichen ein Doppelpunkt geschrieben und damit die Eindeutigkeit wieder hergestellt:

<web:body> Das ist meine Webseite </web:body>

und

<man:body>
<man:height>182 cm</man:height>
<man:weight>85 kg</man:weight>
</man:body>

Die Verwendung von derartigen Präfixen setzt voraus, dass zuvor ein Namesraum, also ein Kontext, festgelegt wurde. Diese Deklarationen sollten immer am Anfang der Instanz als Attribut namens xmlns zum Root-Element erfolgen und haben als Wertzuweisung eine beliebige URL:

<html     xmlns="http://www.w3.org/1999/xhtml"
   xmlns:man="http://www.hki.uni-koeln.de/human">
  
   <head>
          <titel> menschlicher Körper</title>
   </head>
  
   <body>
          <man:body>
                 <man:height>182 cm</man:height>
                 <man:weight>85 kg</man:weight>
          </man:body>
   </body>
</html>

Kommentare

Kommentare sind Bereiche, die nicht interpretiert werden sollen. Diese werden wie folgt notiert:

<!-- Kommentar --> oder
<!-- <Elementname>Inhalt</Elementname> -->