nicht angemeldet
Auge
Auge
Auge
Matthias Apsel
MudGuard
Gunnar Bittersmann
Auge
Hallo
Ich versuche mich an einer DTD für einen eigenen XML-Dialekt. ich habe mir den DTD-Bereich von SelfHTML reingezogen. Für bestimmte Elemente soll folgendes gelten. Sie sind Kindelemente eines anderen Elemnents. Sie sind optional, könne aber, so sie vorhanden sind, mehrfach vorkommen. Getestet ist der Code, den ich hier zeige, bisher nicht.
<!ELEMENT objekttechnik (frequenzbereich, (filtertyp, rueckkanal, (verkabelungstyp)+)*) >
<!ELEMENT frequenzbereich EMPTY >
<!ELEMENT filtertyp #PCDATA >
<!ELEMENT rueckkanal EMPTY >
<!ELEMENT verkabelungstyp EMPTY >
<!ATTLIST frequenzbereich
untergrenze CDATA #IMPLIED
obergrenze CDATA #REQUIRED
>
<!ATTLIST rueckkanal
faehig (ja | nein) "nein"
vorhanden CDATA #IMPLIED
>
<!ATTLIST verkabelungstyp
typ CDATA #REQUIRED
>
Bei der Verschachtelung in der Deklaration von objekttechnik bin ich mir nicht sicher. Das Element frequenzbereich ist verpflichtend, filtertyp, rueckkanal und verkabelungstyp sind optional (*). verkabelungstyp kann, wenn vorhanden, mehrfach vorhanden sein (+). Hat jemand eine Quelle, wo solche Schachtelfälle „menschenlesbar“ beschrieben sind? SelfHTML selbst geht ja nur auf die Regeln selbst aber nicht auf deren Verschachtelungsmöglichkeiten ein.
Der Validome-Validator hat zwar nichts zu meckern, aber manchmal ist ja auch etwas syntaktisch korrekt und hat dennoch eine kaputte Logik.
Tschö, Auge
Hallo Auge,
<!ELEMENT objekttechnik (frequenzbereich, (filtertyp, rueckkanal, (verkabelungstyp)+)*) >
<!ELEMENT frequenzbereich EMPTY >
<!ELEMENT filtertyp #PCDATA >
<!ELEMENT rueckkanal EMPTY >
<!ELEMENT verkabelungstyp EMPTY >
...
#PCDATA gehört in Klammern: <!ELEMENT filtertyp (#PCDATA)>
Ansonsten kann ich nur sagen, dass es sinnvoll ist, eine genaue Beschreibung vorzunehmen und dann das Inhaltsmodell zu präzisieren. Ob + und \* hier alle gewünschten Fälle abdecken, lässt sich ohne Detailkenntnisse nicht beurteilen.
Was damit schon mal funktioniert:
~~~xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE objekttechnik SYSTEM "test.dtd">
<objekttechnik>
<frequenzbereich obergrenze="..."/>
<filtertyp>...</filtertyp>
<rueckkanal/>
<verkabelungstyp typ="..."/>
</objekttechnik>
Grüße,
Thomas
Hallo
<!ELEMENT objekttechnik (frequenzbereich, (filtertyp, rueckkanal, (verkabelungstyp)+)*) >
...
<!ELEMENT filtertyp #PCDATA >
...
>
> #PCDATA gehört in Klammern: <!ELEMENT filtertyp (#PCDATA)>
Das hat mir der Validator während des Schreibens des Eröffnungspostings auch gesagt. Im Original sind die dementsprechend auch vorhanden, hier habe ich sie leider vergessen nachzutragen.
> Ansonsten kann ich nur sagen, dass es sinnvoll ist, eine genaue Beschreibung vorzunehmen und dann das Inhaltsmodell zu präzisieren. Ob + und \* hier alle gewünschten Fälle abdecken, lässt sich ohne Detailkenntnisse nicht beurteilen.
Die glaube ich zu haben. Es gibt Werte, die können, müssen aber nicht übermittelt werden. Für eine Art von Werten („verkabelungstyp“) gilt dabei, dass sie nicht, wenn dann aber auch mehrfach vorkommen können.
`<!ELEMENT objekttechnik (frequenzbereich, (filtertyp, rueckkanal, (verkabelungstyp)+)*) >`{:.language-xml}
Meine Frage ist halt, ob es irgendwo leicht verständliche Beschreibungen solcher Spezialfälle gibt. An der Stelle reicht es eben nicht mehr, zu wissen, dass „()+“ „ein- oder mehrfach“, „()\*“ demgegenüber „kein-, ein- oder mehrfach“ bedeutet. Ist die Verschachtelung etwa überflüssig, weil „(verkabelungstyp)\*“ den Fall „(verkabelungstyp)+“ einschließt? Für so etwas brauche ich Beschreibungen, die ich selbst partout nicht finde.
> Was damit schon mal funktioniert:
>
> ~~~xml
<?xml version="1.0" encoding="UTF-8"?>
> <!DOCTYPE objekttechnik SYSTEM "test.dtd">
> <objekttechnik>
> <frequenzbereich obergrenze="..."/>
> <filtertyp>...</filtertyp>
> <rueckkanal/>
> <verkabelungstyp typ="..."/>
> </objekttechnik>
Nee, das wäre, zumindest, wenn ich der Beschreibung in SelfHTML folge, invalide. Für „rueckkanal“ ist folgende Attributliste definiert.
<!ATTLIST rueckkanal
faehig (ja | nein) "nein"
vorhanden CDATA #IMPLIED
>
SelfHTML führt zu <http://de.selfhtml.org/xml/dtd/attribute.htm#mit_alternativwert@title=Attributen mit festen alternativen Werten> aus:
„Wenn Sie einen solchen Default-Wert (hier: "nein") notieren, ist hinterher keine Angabe mehr dazu möglich, ob das Attribut notwendig (#REQUIRED) oder optional (#IMPLIED) ist. Denn der Default-Wert bewirkt, dass das Attribut intern vom Seite Parser als notwendig interpretiert wird.“
Das Atttribut „faehig“ ist also implizit explizit (#REQUIED).
Tschö, Auge
Hallo
Was damit schon mal funktioniert:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE objekttechnik SYSTEM "test.dtd">
<objekttechnik>
<frequenzbereich obergrenze="..."/>
<filtertyp>...</filtertyp>
<rueckkanal/>
<verkabelungstyp typ="..."/>
</objekttechnik>
>
> Nee, das wäre, zumindest, wenn ich der Beschreibung in SelfHTML folge, invalide. …
Wenn ich der denn selbst mal folgte. Klar ist das völlig leere Element rueckkanal erlaubt, denn es wird der Standardwert "nein" für das Attribut faehig angenommen, wenn es nicht vorhanden ist.
Tschö, Auge
--
Verschiedene Glocken läuteten in der Stadt, und jede von ihnen vertrat eine ganz persönliche Meinung darüber, wann es Mitternacht war.
Terry Pratchett, "Wachen! Wachen!"
ie:{ fl:| br:> va:) ls:[ fo:) rl:( ss:| de:> js:| zu:}
[Veranstaltungsdatenbank Vdb 0.3](http://termindbase.auge8472.de/)
Hallo Auge,
Meine Frage ist halt, ob es irgendwo leicht verständliche Beschreibungen solcher Spezialfälle gibt. An der Stelle reicht es eben nicht mehr, zu wissen, dass „()+“ „ein- oder mehrfach“, „()*“ demgegenüber „kein-, ein- oder mehrfach“ bedeutet. Ist die Verschachtelung etwa überflüssig, weil „(verkabelungstyp)*“ den Fall „(verkabelungstyp)+“ einschließt? Für so etwas brauche ich Beschreibungen, die ich selbst partout nicht finde.
Diese wirst Du auch kaum finden. Die DTD-Syntax gibt letztlich nur Möglichkeiten vor, die man auf das konkrete Problem anwenden kann.
Vielleicht ist auch XML-Schema von Vorteil, da man damit restriktiver Vorgaben machen kann (u. a. minOccurs / maxOccurs) und Datentypen genauer bestimmen kann (xs:integer, xs:date, usw.).
Zudem könnte ein geeigneter XML-Editor helfen, Schemas zu visualisieren. Zur Visualisierung von DTDs ist TreeVision nützlich, das ist aber kein Editor. Eine solche Abbildung habe ich beim Projekt epubMinFlow zur Veranschaulichung der Struktur verwendet.
Ansonsten sage einfach, was konkret beabsichtigt ist. Dann lässt sich vielleicht eine maßgeschneiderte DTD formulieren.
Grüße,
Thomas
Hallo
Meine Frage ist halt, ob es irgendwo leicht verständliche Beschreibungen solcher Spezialfälle gibt. An der Stelle reicht es eben nicht mehr, zu wissen, dass „()+“ „ein- oder mehrfach“, „()*“ demgegenüber „kein-, ein- oder mehrfach“ bedeutet. Ist die Verschachtelung etwa überflüssig, weil „(verkabelungstyp)*“ den Fall „(verkabelungstyp)+“ einschließt? Für so etwas brauche ich Beschreibungen, die ich selbst partout nicht finde.
Diese wirst Du auch kaum finden. Die DTD-Syntax gibt letztlich nur Möglichkeiten vor, die man auf das konkrete Problem anwenden kann.
Und das verhindert (grundsätzlich), dass jemand Beispiele mit Beschreibung erstellt? Klar, die Frage lässt sich subjektiv beantworten; Ich habe nichts dergleichen gefunden, du sagst, ich könne es nicht finden …
Vielleicht ist auch XML-Schema von Vorteil, da man damit restriktiver Vorgaben machen kann (u. a. minOccurs / maxOccurs) und Datentypen genauer bestimmen kann (xs:integer, xs:date, usw.).
Das halte ich für meine ersten Gehversuche auf diesem Gebiet für zuviel des Guten. Zumal die Daten zu vielfältig sind, als dass *ich* das mit solchen strikten Regeln sauber beschreiben könnte. Die DTD nach XML1.0, die keine strikten Datentypen vorschreibt, kommt mir da entgegen.
Ansonsten sage einfach, was konkret beabsichtigt ist. Dann lässt sich vielleicht eine maßgeschneiderte DTD formulieren.
Was soll ich dazu noch sagen? Es kommen Daten zu Aufgaben herein. Dazu gehören eine Adresse, Stammdaten (z.B. Typ, Auftragsnummer) und auch Daten zur der an der Adresse vorhandenen Technik. Was da ankommt, habe ich nun schon in mehreren Postings geschrieben, aber bitte, noch einmal.
1. immer vorhanden: ein Frequenzbereich; Angabe des unteren Limits optional, das obere Limit ist eine Pflichtangabe.
2. kann (evtl. mehrfach) vorhanden sein oder auch nicht: Filtertyp; Inhalt steht, wenn vorhanden, im Element.
3. kann (evtl. mehrfach) vorhanden sein oder auch nicht: Rückkanal; ist er im Netz an der Adresse vorhanden und ist die Gebäudetechnik dafür ausgerüstet?
4. kann (evtl. mehrfach) vorhanden sein oder auch nicht: Verkabelungstyp, wie ist das oder die Hausnetz(e) aufgebaut?
An der Stelle klärt sich die ursprüngliche Frage endgültig. <!ELEMENT objekttechnik (frequenzbereich, (filtertyp, rueckkanal, verkabelungstyp)*) > reicht, denn auch verkabelungstyp ist nicht oder einmal oder mehrmals möglich.
Tschö, Auge
Hallo Auge,
Und das verhindert (grundsätzlich), dass jemand Beispiele mit Beschreibung erstellt? Klar, die Frage lässt sich subjektiv beantworten; Ich habe nichts dergleichen gefunden, du sagst, ich könne es nicht finden …
Ich schrieb, so etwas wird man kaum finden, wüsste jedenfalls spontan keine Quelle. DTD-Syntax ist aber durch die wenigen Möglichkeiten eigentlich leicht zu durchschauen, wenn man die Indikatoren (+ * ?) nicht gleich zu sehr verschachtelt.
An der Stelle klärt sich die ursprüngliche Frage endgültig.
<!ELEMENT objekttechnik (frequenzbereich, (filtertyp, rueckkanal, verkabelungstyp)*) >reicht, denn auch verkabelungstyp ist nicht oder einmal oder mehrmals möglich.
Das bedeutet, frequenzbereich muss genau 1x vorkommen, gefolgt von 0x (filtertyp, rueckkanal, verkabelungstyp) bis n-fach (filtertyp, rueckkanal, verkabelungstyp). Es muss also immer die gesamte Dreiergruppe (…) erscheinen oder fehlen. Wenn das gewünscht ist, dann reicht es so.
Allerdings würde ich um die drei Elemente noch ein Containerelement bauen, etwa parameter. Man sollte auch immer die Perspektive der späteren Verarbeitung der Dokumente im Blick haben, etwa mit XSLT. Für ein parameter-Element lässt sich leicht ein separates Template schreiben, in welchem wiederum auf die Kindelemente zugegriffen werden kann.
Grüße,
Thomas
Hallo
Und das verhindert (grundsätzlich), dass jemand Beispiele mit Beschreibung erstellt? Klar, die Frage lässt sich subjektiv beantworten; Ich habe nichts dergleichen gefunden, du sagst, ich könne es nicht finden …
Ich schrieb, so etwas wird man kaum finden, wüsste jedenfalls spontan keine Quelle. DTD-Syntax ist aber durch die wenigen Möglichkeiten eigentlich leicht zu durchschauen, wenn man die Indikatoren (+ * ?) nicht gleich zu sehr verschachtelt.
Ok, *zu viele* Möglichkeiten gibt es nicht. Was aber bei nicht verstandenen Verschachtelungsregeln passieren kann, sehen wir gleich im Folgenden …
An der Stelle klärt sich die ursprüngliche Frage endgültig.
<!ELEMENT objekttechnik (frequenzbereich, (filtertyp, rueckkanal, verkabelungstyp)*) >reicht, denn auch verkabelungstyp ist nicht oder einmal oder mehrmals möglich.Das bedeutet, frequenzbereich muss genau 1x vorkommen,
… ja …
gefolgt von 0x (filtertyp, rueckkanal, verkabelungstyp) bis n-fach (filtertyp, rueckkanal, verkabelungstyp). Es muss also immer die gesamte Dreiergruppe (…) erscheinen oder fehlen. Wenn das gewünscht ist, dann reicht es so.
… nein.
Beim kacken erwischt! Es soll eben nicht sein, dass wenn, dann alle drei Elemente in der gleichen Anzahl vorkommen müssen. Jedes der optionalen Elemente kann einzeln vorkommen.
Folgende Kombinationen sind möglich:
<objekttechnik>
<frequenzbereich obergrenze="466" />
</objekttechnik>
<!-- oder -->
<objekttechnik>
<frequenzbereich obergrenze="466" />
<filtertyp>OF</filtertyp>
</objekttechnik>
<!-- oder -->
<objekttechnik>
<frequenzbereich obergrenze="466" />
<rueckkanal faehig="ja" vorhanden="ja" />
</objekttechnik>
<!-- oder -->
<objekttechnik>
<frequenzbereich obergrenze="466" />
<verkabelungstyp typ="Baum" />
</objekttechnik>
<!-- oder auch in Kombination -->
<objekttechnik>
<frequenzbereich obergrenze="466" />
<filtertyp>OF</filtertyp>
<rueckkanal faehig="ja" vorhanden="ja" />
<verkabelungstyp typ="Baum" />
<verkabelungstyp typ="Singleline" />
</objekttechnik>
Wenn ich dich richtig verstehe, bedeutet eine gemeinsame Klammerung auch das zwangsläufig gemeinsame Auftreten der Elemente. Wenn ich aber möchte, dass neben dem verpflichtend anzugebenden Frequenzbereich der Filtertyp und/oder der Verkabelungstyp angegeben werden können, aber nicht müssen und auch _nicht zusammen_ müssen, brauche ich für jedes der Elemente eine eigene Klammerung „(a, (b)*, c()*)“?
Der Rückkanal ist im übrigen (physikalisch an der Adresse) nur kein- oder einmal da. Da das in XML nicht definierbar ist, überlege ich, an der Datenquelle das Element *immer* einzufügen und das in der DTD auch so vorzuschreiben. In den obigen Beispielen ist das noch nicht berücksichtigt.
Allerdings würde ich um die drei Elemente noch ein Containerelement bauen, …
Ich denke, mit der Info, dass die drei optionalen Elemente nicht zwingend zusammen gehören, hat sich die Idee erledigt.
Tschö, Auge
Hallo Auge,
Folgende Kombinationen sind möglich:
[…]
Werden damit abgedeckt:
<!ELEMENT objekttechnik (frequenzbereich, (filtertyp?, rueckkanal?, verkabelungstyp?)*)>
Grüße,
Thomas
Hallo
Folgende Kombinationen …
… Werden damit abgedeckt:
<!ELEMENT objekttechnik (frequenzbereich, (filtertyp?, rueckkanal?, verkabelungstyp?)*)>
Aha, ich rekapituliere: Jedes der optionalen Elemente kann oder kann nicht vorhanden sein. Wenn sie vorhanden sind (einzeln ioder gemeinsam ist egal) können sie ein oder mehrfach vorkommen. Habe ich das richtig verstanden?
Tschö, Auge
Hallo Auge,
Aha, ich rekapituliere: Jedes der optionalen Elemente kann oder kann nicht vorhanden sein. Wenn sie vorhanden sind (einzeln ioder gemeinsam ist egal) können sie ein oder mehrfach vorkommen. Habe ich das richtig verstanden?
Ja, die drei Elemente können beliebig oft in beliebiger Reihenfolge auftreten, also auch nicht.
Das lässt sich auch über die ODER-Bedingung | in Verbindung mit * ausdrücken:
<!ELEMENT objekttechnik (frequenzbereich, (filtertyp | rueckkanal | verkabelungstyp)*)>
Grüße,
Thomas
Hallo
Aha, ich rekapituliere: Jedes der optionalen Elemente kann oder kann nicht vorhanden sein. Wenn sie vorhanden sind (einzeln ioder gemeinsam ist egal) können sie ein oder mehrfach vorkommen. Habe ich das richtig verstanden?
Ja, die drei Elemente können beliebig oft in beliebiger Reihenfolge auftreten, also auch nicht.
Das lässt sich auch über die ODER-Bedingung | in Verbindung mit * ausdrücken:
<!ELEMENT objekttechnik (frequenzbereich, (filtertyp | rueckkanal | verkabelungstyp)*)>
Siehste, genau sowas suche ich, auch wenn mein akutes Anliegen gelöst ist. Ich danke dir und überlege, wie ich damit beginnen kann, das in unserem Wiki zu hinterlegen.
Tschö, Auge
Om nah hoo pez nyeetz, Auge!
Ich danke dir und überlege, wie ich damit beginnen kann, das in unserem Wiki zu hinterlegen.
http://wiki.selfhtml.org/wiki/Benutzer:Auge/Spielwiese Einfach drauf los schreiben, dich nicht darum scheren, wie es aussieht. Wenn es dann doch beginnen soll auszusehen, nachfragen. Am besten am kommenden Wochenende in Nürnberg.
Matthias
Hallo
Ich danke dir und überlege, wie ich damit beginnen kann, das in unserem Wiki zu hinterlegen.
http://wiki.selfhtml.org/wiki/Benutzer:Auge/Spielwiese Einfach drauf los schreiben, dich nicht darum scheren, wie es aussieht. Wenn es dann doch beginnen soll auszusehen, nachfragen.
Ok
Am besten am kommenden Wochenende in Nürnberg.
Gibt's Lebkuchen?
Tschö, Auge
Om nah hoo pez nyeetz, Auge!
Am besten am kommenden Wochenende in Nürnberg.
Gibt's Lebkuchen?
Daran soll es nicht scheitern, die Supermärkte sind voll davon. Ich sag Matthias Scharwies Bescheid, er soll welche besorgen.
Matthias
Om nah hoo pez nyeetz, Auge!
verkabelungstyp kann, wenn vorhanden, mehrfach vorhanden sein (+).
Betrachte diese Antwort als völlig blauäugig.
Du möchtest, dass ein Element zwei gleichlautende Attribute aber mit unterschiedlichen Werten haben soll?
Zum Vergleich:
<div class="foo" class="bar">
Wäre da nicht
<div class="foo bar">
sinnvoller?
Matthias
Hi,
verkabelungstypkann, wenn vorhanden, mehrfach vorhanden sein (+).Betrachte diese Antwort als völlig blauäugig.
Du möchtest, dass ein Element zwei gleichlautende Attribute aber mit unterschiedlichen Werten haben soll?
Nein. verkabelungstyp soll ein Element sein, und ein Attribut namens typ haben.
Und das Element objekttechnik soll (unter anderem) mehrere verkabelungstyp-Elemente enthalten dürfen.
So lese ich zumindest gegebenen die DTD-Teile ...
cu,
Andreas
Om nah hoo pez nyeetz, MudGuard!
Nein. verkabelungstyp soll ein Element sein, und ein Attribut namens typ haben.
Und das Element objekttechnik soll (unter anderem) mehrere verkabelungstyp-Elemente enthalten dürfen.So lese ich zumindest gegebenen die DTD-Teile ...
Ja. Lesen war das Zauberwort ;-)
Matthias
@@Matthias Apsel:
nuqneH
Wäre da nicht
<div class="foo bar">
sinnvoller?
Unbedingt.
Soll heißen:
<div class="foo" class="bar">
ist gar nicht sinnvoll.
Nicht valide. Nicht mal wohlgeformt:
“An attribute name MUST NOT appear more than once in the same start-tag or empty-element tag.” [XML §3.1]
Qapla'
Hallo
verkabelungstypkann, wenn vorhanden, mehrfach vorhanden sein (+).
Inklusive des Verständnisproblems, ob das in einer Deklaration, dass das Element eventuell überhaupt nicht da ist, sinnvoll ist. Die lautet ja:
<!ELEMENT objekttechnik (…, (…, …, (verkabelungstyp)+)*) >
verkabelungstyp ist Element innerhalb objekttechnik. Es muss nicht, darf aber vorkommen („()*“). Nun hinterher noch zu bestimmen, dass es ein oder mehrfach da sein darf („()+“), obwohl ich gerade zuvor festgelegt habe, dass es nicht, ein oder mehrfach da sein darf, verunsichert mich halt etwas.
Das meinte ich mit „manchmal ist ja auch etwas syntaktisch korrekt und hat dennoch eine kaputte Logik.“.
Du möchtest, dass ein Element zwei gleichlautende Attribute aber mit unterschiedlichen Werten haben soll?
<plenk class="aehh????????????????????????????" />
<div class="foo" class="bar">
Wo liest du das?
Falls du das Attribut faehig des Elements rueckkanal meinst, faehig (ja | nein) "nein" bedeutet, dass es *ein* solches Attribut gibt, das den Wert ja ODER nein haben darf, wobei bei nicht explizit vorhandenem Attribut „nein“ als Standardwert angenommen wird.
Tschö, Auge
