DTD-Design: Hart oder Herzlich?

[Bernhard Peissl]

Grüssi Cheatah!

*** Cheatah for President *** - vote, vote, vote !!!
Ich lehne ab, da dieses Amt für mich einen Machtverlust darstellt.
;-)

*lol*

Bin aber umgeschwenkt, zu einem etwas generischeren Ansatz:

Bedenke, daß Du dadurch in jedem <Detail> die selben Tags zuläßt. Es unterscheiden sich aber z.B. <Zielgruppe> und <Kursziel> durch <Block> und <UListe>.

War schlecht dargestellt in diesem Auszug, beide sind in beiden erlaubt!

<!ENTITY % BlockElemente  "#PCDATA|Block|NListe|UListe|Bild">

Und diese Block-Level-Elemente können überall (innerhalb <Detail> oder früher mal <zielgruppe>,<kursziel>,..) vorkommen!

Ich habe heute mal mit den Leuten gesprochen. Ich werde mich wohl entscheiden für eine Element-Atrribut-Mixtour ;-) Die "unstrukturierteren" Daten (Zielgruppe, Kursinhalt,...), die einfach runtergeschrieben werden, bleiben in den <detail>s mit ihren Titeln als Attribute, und Sachen wie <Preis>, <Ansprechpartner>, ... werden tiefer verschachtelt, und bekommen eigene Elemente. Weiters wird sich eine Trennung in Kopfdaten und Seminarinfo anbieten.

<Dokument>
 <DokInfo>....</DokInfo>
 <Seminar>

<Seminarinfo>
   <Seminartitel> ... </Seminartitel>
   <Untertitel> ... </Untertitel>
   <Preis einheit="EUR" ust="20" in_ex="exkl"> ... </Preis>
   <Ansprechpartner>
    <Name> ... <Tel> ... <Email> ...
   </Ansprechpartner>
  </Seminarinfo>

<Seminardetails>
   <SeminarDetail Titel="Zielgruppe"> ... </SeminarDetail>
   <SeminarDetail Titel="Seminarinhalt"> ... </SeminarDetail>
   <SeminarDetail Titel="Seminarziel"> ... </SeminarDetail>
  </Seminardetails>

</Seminar>
</Dokument>

Somit kann ich mir auch die Möglichkeit offenhalten, für andere Veranstaltungstypen (Kongresse, Lehrgänge) ein anderes Containerelement einzubauen, dann gibts eben nicht nur ein <seminar> das alles umfasst, sondern eben auch <kongress> oder <lehrgang>, die wieder andere <Kongressdetails> bzw. <Lehrgangdetails> haben. So wirds glaube ich leichter zu handhaben sein. Denn bei letzteren beiden wird sich eine strikte DTD nicht durchziehen lassen :-/ So hab ich wenigstens bei den <Seminar>en eine klare Linie. Bei den "besseren" Angeboten scheint es (nach heutigem Gespräch) sogar erwünscht zu sein, dass jedes anders aussieht!

Übrigens reicht die Angabe von EUR bei allen beteiligten Währungen, da sich die Werte umrechnen lassen _müssen_. Bei mehreren Tags hast Du u.U. falsche Daten gespeichert.

Ja schon, aber den casting-funktionen in XSLT trau ich noch nicht so übern Weg. Wenn da einer ',' statt '.' eingibt, und sich das Ding dann nicht umrechnen lässt, ist das nicht so toll!

Ich hab leider nur einen SAX-Parser (Expat) zur Verfügung und blick in der ereignisgesteuerten Programmierung noch nicht so wirklich durch, DOM wär mir lieber.

Laß das ändern.

Wird kaum gehen! Ich werde mit PHP arbeiten müssen, und dort ist nunmal der Expat standardmässig dabei! Ich muss schon zusehen dass mein Provider mir Sablotron (XSLT-Extension von PHP) draufinstalliert, wenn ich dann auch noch mit der DomXML-Extension antanze, wird er sich was pfeifen! Abgesehen davon, ist expat im gegensatz zum DomXML fertig und ausgereift.

Gibts für Perl eigentlich ein (brauchbares) XSLT-Modul? Notfalls würd ich dann ev. umsteigen! Wie arbeitet dieses Forum eigentlich? Nehmt ihr SAX oder DOM?

Auch XSLT stell ich mir komplizierter vor, wenn es für jedes Element zig Unterelemente gibt.

Mag sein, aber verschiedene Elemente sollen i.d.R. auch verschieden repräsentiert werden, was gegen die Attributisierung spricht.

Bei den <Detail>-Tags eben nicht, da nehmen eigene Elemente eigentlich nur Platz weg für Templates, und für jedes im Nachhinein hinzugefügte Element muss ein Template neu dazugeschrieben werden. Wenn ich die Titel als Attribute dazugebe, reicht eine aktualisierung der DTD!

lg bernhard