nicht angemeldet
DTD-Design: Hart oder Herzlich?
0 0 Herzenssachen sind immer hart!
0
DTD-Design: Hart oder Herzlich?
Grüssi!
Ich arbeite gerade an meiner ersten DTD (für einen Seminaranbieter). Und ich schwanke dabei zwischen 2 Polen:
- Einheitliches Erscheinungsbild
- Einfache Bedienung für die XML-Schreiberlinge
Da stehe ich an. Sollte man die DTD möglichst grosszügig gestalten, sodass die Verfasser selbst bestimmen können welche Werte ihre Attribute haben sollen, welche Elemente sie wo weglassen können, ... oder sollte man ihnen eine (umfassende, vorher durchdiskutierte) begrenzte Menge an gültigen Werten, Elementen vorschreiben.
Konkretes Beispiel:
<!ELEMENT SeminarDetail (%BlockElemente;)*>
<!ATTLIST SeminarDetail Titel (Zielgruppe|Voraussetzungen|Seminarziel|Nutzen|Hinweis|Inhalt|Referent|Anmeldung) #REQIURED>
oder wäre es ev. besser so:
<!ELEMENT SeminarDetail (%BlockElemente;)*>
<!ATTLIST SeminarDetail Titel CDATA #REQUIRED>
Vorteil: Benutzerdreundliches Editieren, Jeder Redakteur kann die XML-Datei an seine Bedürfnisse anpassen.
Nachteil: Jeder kocht seine eigene Suppe, und das einheitliche Erscheinungsbild geht den Bach runter.
Gibts da einen Kompromiss, oder muss man das von Fall zu Fall selber abwägen, was nun gscheiter ist?
Und thematisch dazupassend: Ist es überhaupt sinnvoll xml für nur leicht strukturierte Daten zu verwenden? Ich verwende derzeit eine ausgewählte Teilmenge von HTML-Elementen, und ein paar selbstdefinierte Container-Elemente, bzw. Metainformationen über die Datei selber.
Beipieldatei:
http://www.wt-akademie.at/DetailProgramm.xml
http://www.wt-akademie.at/DetailProgramm.dtd
Wäre es ev. zu überlegen, meine "selbstgebastelten HTML-Elemente" rauszunehmen, und stattdessen gleich den ganzen HTML4-Standard in einem Namespace zu erlauben?
Ich würde gern eure Meinung dazu hören.
lg bernhard
-
Hi,
Und ich schwanke dabei zwischen 2 Polen:
klingt nach einer Meinungsumfrage... also gibt's im folgenden auch nur meine Meinung :-)
- Einfache Bedienung für die XML-Schreiberlinge
Hierzu werden Tools benutzt.
oder sollte man ihnen eine (umfassende, vorher durchdiskutierte) begrenzte Menge an gültigen Werten, Elementen vorschreiben.
Oder. Dadurch ist das Konzept auch durchdachter, was Fehler minimiert.
Wobei Planung natürlich nur der Ersatz des Fehlers durch den Irrtum darstellt :-)
Nachteil: Jeder kocht seine eigene Suppe, und das einheitliche Erscheinungsbild geht den Bach runter.
Weiterer Nachteil: Fehler (z.B. Tipp-) werden nicht erkannt. Bei einem strikten DTD crasht es spätestens zur Compiletime.
Gibts da einen Kompromiss, oder muss man das von Fall zu Fall selber abwägen, was nun gscheiter ist?
Sicher kannst Du auch bei einigen Attributen davon ausgehen, daß die Liste permanent erweitert wird, was u.U. die unspezifizierte Variante vorteilhaft macht. Wenn Du aber nur ein begrenztes Set möglicher Werte absiehst, dann solltest Du dieses auch definieren.
Und thematisch dazupassend: Ist es überhaupt sinnvoll xml für nur leicht strukturierte Daten zu verwenden?
Kommt drauf an, wie "leicht strukturiert" die Daten sind, und was Du mit ihnen machen willst. Wir exportieren auch gelegentlich DB-Tabellen als (eindimensionales) XML-File.
Ich verwende derzeit eine ausgewählte Teilmenge von HTML-Elementen,
Hm, das ist nicht unbedingt positiv... wenn auch nicht zwingend negativ :-)
Wäre es ev. zu überlegen, meine "selbstgebastelten HTML-Elemente" rauszunehmen, und stattdessen gleich den ganzen HTML4-Standard in einem Namespace zu erlauben?
HTML hat einen ganz speziellen Anwendungs-Ansatz. Wenn dieser auf Deine Daten auch anzuwenden ist, kannst Du natürlich versuchen, HTML zu verwenden - wobei Du dann vielleicht XHTML bevorzugen solltest. Wenn Du hingegen bestimmte Daten unterscheidbar speichern möchtest, würde ich ehrlich gesagt von HTML ganz abgehen und etwa <link> anstatt <a> verwenden.
Cheatah
-
Grüssi Cheatah,
klingt nach einer Meinungsumfrage... also gibt's im folgenden auch nur meine Meinung :-)
Ich will weder mehr noch weniger ;-)
- Einfache Bedienung für die XML-Schreiberlinge
Hierzu werden Tools benutzt.
Das weiss ich, und das werden wir ja auch, aber ich meinte damit eher, dass ihnen durch mehr gestalterische Freiheit das Editieren leichter fallen würde.
oder sollte man ihnen eine (umfassende, vorher durchdiskutierte) begrenzte Menge an gültigen Werten, Elementen vorschreiben.
Oder. Dadurch ist das Konzept auch durchdachter, was Fehler minimiert.
Tja, dieser Meinung war ich auch zuallererst, doch ich kenne meine Pappenheimer mittlerweile ziemlich gut. Mit fixen Werten geht das vielleicht ein Jahr gut, aber dann kommt irgendwann eine Veranstaltung, die so komplett anders als alle anderen ist, irgendein Kongress oder so, ein ganz wichtiger, der viel Geld bringt, und der will dann mit Sicherheit Attributwerte die ich nicht eingeplant habe, und wenn ich das einmal einreissen lasse, dann komm ich mit dem Hinzufügen von gültigen Attributwerten in die DTD gar nicht mehr nach :-(
Drum dachte ich, ich lass ihnen gleich die Wahl. Aber leider gibts sowas wie "mixed Content" (bei den Elementdeklarationen) bei den ATTLIST's leider nicht. Am liebsten wär mir eine Anzahl vordefinierter Attributwerte, und dann zusätzlich ein CDATA, damit man reinschreiben kann was man will, wenn keiner der vordefinierten passt. Das würde zumindest das wilde Wuchern der Seminar-Beschreibungen verhindern.
Also sowas wie:
<!ATTLIST SeminarDetail Titel (CDATA|Zielgruppe|Voraussetzungen|Seminarziel|Nutzen|Hinweis|Inhalt|Referent|Anmeldung) #REQIURED>
Wobei Planung natürlich nur der Ersatz des Fehlers durch den Irrtum darstellt :-)
Muss ich das jetzt verstanden haben? *fg* War das Nietzsche?
Weiterer Nachteil: Fehler (z.B. Tipp-) werden nicht erkannt. Bei einem strikten DTD crasht es spätestens zur Compiletime.
Stimmt, hab ich so noch gar nicht gesehen! Was heisst in diesem Zusammenhang "Compiletime"?
Sicher kannst Du auch bei einigen Attributen davon ausgehen, daß die Liste permanent erweitert wird, was u.U. die unspezifizierte Variante vorteilhaft macht. Wenn Du aber nur ein begrenztes Set möglicher Werte absiehst, dann solltest Du dieses auch definieren.
Den letzten Satz habe ich leider nicht verstanden.
Und thematisch dazupassend: Ist es überhaupt sinnvoll xml für nur leicht strukturierte Daten zu verwenden?
Kommt drauf an, wie "leicht strukturiert" die Daten sind, und was Du mit ihnen machen willst. Wir exportieren auch gelegentlich DB-Tabellen als (eindimensionales) XML-File.
Hast du dir die Beipieldatei angesehen (Link)? Ich meinte damit, dass meine Dateien nicht gerade sehr tief verschachtelt sind, und ausser den Textverarbeitenden (HTML) Elementen, nicht sehr viel strukturiert wird.
HTML hat einen ganz speziellen Anwendungs-Ansatz. Wenn dieser auf Deine Daten auch anzuwenden ist, kannst Du natürlich versuchen, HTML zu verwenden - wobei Du dann vielleicht XHTML bevorzugen solltest.
Wollte XHTML schreiben ;-) Es geht grösstenteils wirklich nur um Präsentationszwecke. Die dynamischen Daten (z.b. Termine) kommen aus der Datenbank, und sind vorerst nicht geplant in XML abgelegt zu werden!
Wenn Du hingegen bestimmte Daten unterscheidbar speichern möchtest, würde ich ehrlich gesagt von HTML ganz abgehen und etwa <link> anstatt <a> verwenden.
Es geht mir hauptsächlich darum, eine Rohdatei zu haben, aus der ich dann - für verschiedenste Zwecke - in die unterschiedlichen Formate konvertieren kann. Also z.b. ein Flyer, der gedruckte Seminarkatalog, grafisch aufbereitete PDF-Folder, Text-Version für die Homepage, ev. WML-Version, ... alles aus der XML-Datei, und es sollte für die Redakteure eben leichter verständlich/erlernbar sein als die HTML-Tags!
-
Hi,
aber ich meinte damit eher, dass ihnen durch mehr gestalterische Freiheit das Editieren leichter fallen würde.
das ist Ansichtssache. Eine Auswahl einiger weniger Möglichkeiten ist oft leichter, als sich den richtigen Namen erst ausdenken zu müssen. Wie hast Du beispielsweise den Themenbereich Deines Postings gewählt?
Mit fixen Werten geht das vielleicht ein Jahr gut,
Das wäre schon ziemlich lang. Du solltest die Werteliste nicht als für alle Zeit endgültig ansehen, sondern damit rechnen, sie beizeiten erweitern zu müssen. Jede Erweiterung erfordert wieder Gehirnschmalz, um mögliche Konsequenzen abschätzen zu können.
Seit wann gibt es in HTML align="justify"?
Wobei Planung natürlich nur der Ersatz des Fehlers durch den Irrtum darstellt :-)
Muss ich das jetzt verstanden haben? *fg* War das Nietzsche?
Keine Ahnung, Nietzsche ist tot - meinte zumindest Gott, als ich sie das letzte mal traf ;-)
Was heisst in diesem Zusammenhang "Compiletime"?
Irgendwas wird mit den Werten doch gemacht, wenn sie eingetragen wurden. Ich nehme an, die XML-Datei wird irgendwo verwendet. Dies geschieht oft beim Start oder sogar der Kompilierung eines Programms, was ich mal pauschal als Compiletime zusammengefaßt habe.
Wenn Du aber nur ein begrenztes Set möglicher Werte absiehst, dann solltest Du dieses auch definieren.
Den letzten Satz habe ich leider nicht verstanden.
Wenn Du meinst, daß nur bestimmte Werte benutzt werden, solltest Du diese nennen.
Ich meinte damit, dass meine Dateien nicht gerade sehr tief verschachtelt sind,
Das allein ist noch kein Indiz für eine "leichte Struktur". Die enthaltenen Daten können ebenfalls ausschlaggebend sein - beispielsweise ist XML gegenüber z.B. CSV vorteilhaft, wenn Du Umbrüche in Werten haben kannst.
Es geht grösstenteils wirklich nur um Präsentationszwecke.
Kein Grund, (X)HTML zu nehmen ;-)
Ein "sauberes" (menschenlesbares) XML mit einem passenden XSL sind schon sehr sinnvoll, wenn Du nicht gleich statische Dateien erzeugen willst.
Es geht mir hauptsächlich darum, eine Rohdatei zu haben, aus der ich dann - für verschiedenste Zwecke - in die unterschiedlichen Formate konvertieren kann.
Trenne Dich von (X)HTML. Schreibe ein DTD, das tunlichst unbeeinflußt ist von Dir bekannten Tags. <img> ist nicht gut, wenn Du eigentlich <MitarbeiterFoto> meinst - es wird Dir spätestens bewußt, wenn Du unterschiedliche Bilder referenzieren willst.
und es sollte für die Redakteure eben leichter verständlich/erlernbar sein als die HTML-Tags!
Genau deswegen: sprechende Tags! :-)
Cheatah
-
Moin,
Genau deswegen: sprechende Tags! :-)
gibts da schon ein Plugin fuer den IE fuer? ;-)
Viele Gruesse
n.d.p.
-
Grüssi Cheatah!
das ist Ansichtssache. Eine Auswahl einiger weniger Möglichkeiten ist oft leichter, als sich den richtigen Namen erst ausdenken zu müssen. Wie hast Du beispielsweise den Themenbereich Deines Postings gewählt?
Tja, da hast du den Nagel auf den Punkt getroffen! Das ist im Grunde genau dasselbe! Nur gibts bei uns in der Firma nicht nur einen sondern sehr viele Bio's, die ihre eigenen Themenbereiche gestalten wollen, und diesem Ansturm muss die DTD gerecht werden! Abgesehen davon finde ich auch nicht immer den reichtigen Themenbereich. Hierfür hätte ich z.b. gerne (DTD) genommen. Als Besucher würde man von einerseits schneller kapieren worums geht, wenn das Fettgedruckte Thema schon alles sagt, andererseits würde sich die ganze Übersichtlichkeit ins Gegenteil wandeln, wenn 1000 verschiedene Themen auf der Hauptseite herumhirschen!
Mit fixen Werten geht das vielleicht ein Jahr gut,
Das wäre schon ziemlich lang. Du solltest die Werteliste nicht als für alle Zeit endgültig ansehen, sondern damit rechnen, sie beizeiten erweitern zu müssen. Jede Erweiterung erfordert wieder Gehirnschmalz, um mögliche Konsequenzen abschätzen zu können.
oh, ups, siehst du, das sind eben so die Erfahrungswerte, die mir abgehen. Ich hätte mir eigentlich gedacht, dass - einmal designed - eine DTD steht bis zum Jüngsten Tag, denn zumeist wird sie ja auch nicht von den Leuten erstellt, die die XML-Dateien pflegen sondern von einer externen Firma !?
Wobei Planung natürlich nur der Ersatz des Fehlers durch den Irrtum darstellt :-)
Muss ich das jetzt verstanden haben? *fg* War das Nietzsche?
Keine Ahnung, Nietzsche ist tot - meinte zumindest Gott, als ich sie das letzte mal traf ;-)
*** Cheatah for President *** - vote, vote, vote !!! - Wo ihr immer eure Sprüche her habt! Das war wiedermal ein grenzgenialer!
Trenne Dich von (X)HTML. Schreibe ein DTD, das tunlichst unbeeinflußt ist von Dir bekannten Tags. <img> ist nicht gut, wenn Du eigentlich <MitarbeiterFoto> meinst - es wird Dir spätestens bewußt, wenn Du unterschiedliche Bilder referenzieren willst.
Also, erst wollte ich die xml-datei folgendermassen aufbauen:
<Zielgruppe>
<Block> [...] </Block>
</Zielgruppe>
<Voraussetzung>
[...]
</Voraussetzung>
<Kursziel>
<UListe>
[...]
</UListe>
</Kursziel>Bin aber umgeschwenkt, zu einem etwas generischeren Ansatz:
<Detail Titel="Zielgruppe">
<Block> [...] </Block>
</Detail>
<Deatil Titel="Voraussetzung">
[...]
</Detail>
<Deatil Titel="Kursziel">
<UListe>
[...]
</UListe>
</Detail>=> also eher die herzliche Variante. Wenn ich allerdings nun aus deinem und Thomas' Posting die Schlüsse ziehe, so empfiehlt sich anscheinend doch eher die Harte Variante!
<Preis>
<ats>12345</ats>
<eur>123.45</eur>
<Steuer>exkl. 20 % USt</Steuer>
<Kommentar>
Erfrischungen und Pausengetränke sind in der Kursgebühr enthalten!
</Kommentar>
</Preis>statt:
<Detail Titel="Preis">
Die Teilnahmegebühr beträgt ATS 12345,-- (EUR 123.45) exklusive 20% Umsatzsteuer
<Block>
Erfrischungen und Pausengetränke sind in der Kursgebühr enthalten!
</Block>
</Detail>Aber ich dachte mir, je mehr Elemente, desto schwieriger wird dann das Parsen. 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. Auch XSLT stell ich mir komplizierter vor, wenn es für jedes Element zig Unterelemente gibt.
Alles in allem ein kräftiges => :-/ oder => ?
lg bernhard
-
Hi,
Nur gibts bei uns in der Firma nicht nur einen sondern sehr viele Bio's, die ihre eigenen Themenbereiche gestalten wollen, und diesem Ansturm muss die DTD gerecht werden!
laß alle diese Bios (btw: Du hast den Goldenen Apo'stroph des Monats gewonnen *g*) Vorschläge machen und begründen(!), welche Bereiche gewünscht sind. Diskutiere diese durch. Fasse sinnvoll zusammen, streiche weniger wichtiges. Versuche dabei, möglichst alle gewünschten Bereiche "irgendwo" unterbringen zu können, tunlichst ohne zu viel in ein "Sonstiges" zu stecken. Am Ende kommt ein Set heraus, das bis auf weiteres als verbindlich angesehen werden muß: Jeder hat frühzeitig die Möglichkeit, seine Argumente pro und kontra einen Bereich zur Diskussion zu stellen.
Abgesehen davon finde ich auch nicht immer den reichtigen Themenbereich.
Natürlich nicht, warum auch? :-)
Hierfür hätte ich z.b. gerne (DTD) genommen.
Zu feine Spezialisierung ist auch nicht gut. Wenn DTD ein Thema wäre, das nichts mit anderen (wie XML) gemein hätte, wäre das ein gutes Argument für den Themenbereich - da es aber gewissermaßen die Basis eines jeden XML darstellt, ist der Punkt solange überflüssig, wie es keine prozentual bemerkenswerte Menge DTD-Beiträge innerhalb des Bereiches XML gibt.
Ich hätte mir eigentlich gedacht, dass - einmal designed - eine DTD steht bis zum Jüngsten Tag, denn zumeist wird sie ja auch nicht von den Leuten erstellt, die die XML-Dateien pflegen sondern von einer externen Firma !?
Im Prinzip stimmt das ja auch. Allerdings findest Du beim W3C sowohl ein DTD für HTML 4.0, als auch eines für HTML 4.01. Got it? :-)
*** Cheatah for President *** - vote, vote, vote !!!
Ich lehne ab, da dieses Amt für mich einen Machtverlust darstellt.
;-)
Also, erst wollte ich die xml-datei folgendermassen aufbauen:
[...]
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>. Wenn auch <Kursziel><Block/></> eine gültige Schachtelung darstellt, ist das Abfeiern über ein Attribut legitim.
<Preis>
<ats>12345</ats>
<eur>123.45</eur>Hm.
<Preis> <!-- Wobei ich <Angebot><Preis currency=.../></> bevorzugen würde. -->
<Wert currency="ATS">12345</Wert>
<Wert currency="EUR">123.45</Wert>
[...]Ü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.
<Detail Titel="Preis">
Die Teilnahmegebühr beträgt ATS 12345,-- (EUR 123.45) exklusive 20% UmsatzsteuerHier sind die eigentlichen Informationen nicht zugänglich. Wenn das egal ist - okay!
Aber ich dachte mir, je mehr Elemente, desto schwieriger wird dann das Parsen.
Nö. XML entspricht einer Objektstruktur.
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.
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.
Alles in allem ein kräftiges => :-/ oder => ?
Ein kräftiges ":-?" ;-)
Cheatah
-
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
-
Moin,
Ü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!die Leute koennen sich beim Schreiben von XML-Dokumenten ruhig ein bisschen Muehe geben, finde ich.
Gibts für Perl eigentlich ein (brauchbares) XSLT-Modul?
ich bin mir nicht sicher, aber glaube, nichts was den Standard vollstaendig repraesentiert.
Wie arbeitet dieses Forum eigentlich? Nehmt ihr SAX oder DOM?
uuh ;)
also:
Die Transformation XML => Darstellung passiert mittel stinknormaler Templates (nix XSL, aus eben erwaehntem und Performancegruenden)
Das XML-Parsing der Threaddateien, der Konfiguration und der Templates (XML, aber nur weils schick ist ;): XML::DOM, es ist aber abzusehen, dass das aus Effizienzgruenden, da wo es geht auf direkte Callbacks von XML::Parser umgestellt wird.
Die Hauptdatei wird mit zwei fetten Regexps geparst (http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/selfforum/selfforum-cgi/shared/Posting/_lib.pm?rev=1.26&content-type=text%2Fvnd.viewcvs-markup&only_with_tag=HEAD, sub get_all_threads [nur, falls es dich interessiert ;)]).Viele Gruesse,
n.d.p.
-
Grüssi,
die Leute koennen sich beim Schreiben von XML-Dokumenten ruhig ein bisschen Muehe geben, finde ich.
Tja, das kannst du ihnen sicher auch persönlich erklären oder? Dass sie auf jeden Buchstaben aupassen sollen ;-) Leider ist das Verständnis für solche "Kleinigkeiten" bei Leuten, die Netscape für eine Surf-Bekleidung-Herstellungs-Firma halten, sehr spärlich gesäät!
Gibts für Perl eigentlich ein (brauchbares) XSLT-Modul?
ich bin mir nicht sicher, aber glaube, nichts was den Standard vollstaendig repraesentiert.
Sablotron gibts auch für Perl:
XML::Sablotron -> http://www.gingerall.cz/charlie-bin/get/webGA/act/xml-sab.actEs ist zwar an manchen Stellen etwas Buggy, aber im grossen und ganzen wahrscheinlich einer der standardkompatibelsten die es für Perl/Php als Module derzeit gibt! Ich bin noch nicht an seine Grenzen gestossen, da ich derzeit noch mit eher XML-technischen Dingen beschäftigt bin, wie man am Titel meines Posting ablesen kann ;-)
Wie arbeitet dieses Forum eigentlich? Nehmt ihr SAX oder DOM?
also:
Schade, ich dachte ich kann dir jetzt ein paar Expat-Tricks entlocken :-/
Die Transformation XML => Darstellung passiert mittel stinknormaler Templates (nix XSL, aus eben erwaehntem und Performancegruenden)
Ihr verzichtet aus Performance-Gründen auf XSL setzt aber DOM statt SAX ein? Egal, vielleicht könntest du kurz mal umreissen wie das mit den templates funktioniert im Forum?
Das XML-Parsing der Threaddateien, der Konfiguration und der Templates (XML, aber nur weils schick ist ;): XML::DOM, es ist aber abzusehen, dass das aus Effizienzgruenden, da wo es geht auf direkte Callbacks von XML::Parser umgestellt wird.
Hmmm, jetzt hab ich wenigstens mal gesehen, wo diese vielsagenden Fehlermeldungen herkommen! *g* Feine, Idee diese Templates, an sich, werd mal sehen ob sich das auch für uns einsetzen lässt, ansich ist so eine Seite von uns auch immer irgendwie gleich gestrickt.
Allerdings frage ich mich noch ein wenig, wie ihr die Werte in die Templates bekommt, bzw. was z.b. "{&& LINK_SELFAKTUELL &&}" zu bedeuten hat. Dient das nur als Markierungsstelle für eine Regexp, oder ist das irgendsoein durchgeknallter Perl-Trick?
Abgesehen davon scheint der Einsatz von XML für diese Templates doch mehr Modesklaverei, als Zusatznutzen zu sein ;-)
Die Hauptdatei wird mit zwei fetten Regexps geparst (http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/selfforum/selfforum-cgi/shared/Posting/_lib.pm?rev=1.26&content-type=text%2Fvnd.viewcvs-markup&only_with_tag=HEAD, sub get_all_threads [nur, falls es dich interessiert ;)]).
*schluck* und ich dachte bisher, mit einem genügend dickem Zeitpolster könnte ich jede Perl-Datei (wenigstens) "lesen"! Aber wenn ich nicht wüsste was dieses Modul (ungefähr) macht, könnte es auch in chinesisch geschrieben sein !!! Wahnsinn :-)
lg bernhard
-
Hi,
die Leute koennen sich beim Schreiben von XML-Dokumenten ruhig ein bisschen Muehe geben, finde ich.
Tja, das kannst du ihnen sicher auch persönlich erklären oder?
klar doch! Schließlich willst Du ein Frontend zur Verfügung stellen, über das die XML-Daten eingepflegt werden - und dieses kann bei Fehlern wahlweise warnen oder sie korrigieren.
die Netscape für eine Surf-Bekleidung-Herstellungs-Firma halten,
*lol* :-)
Cheatah
-
Moin,
die Leute koennen sich beim Schreiben von XML-Dokumenten ruhig ein bisschen Muehe geben, finde ich.
Tja, das kannst du ihnen sicher auch persönlich erklären oder? Dass sie auf jeden Buchstaben aupassen sollen ;-)wenn sie keine technischen Dokumente schreiben koennen, muessen sie halt jemanden bezahlen, der es kann *schulterzuck*
Gibts für Perl eigentlich ein (brauchbares) XSLT-Modul?
ich bin mir nicht sicher, aber glaube, nichts was den Standard vollstaendig repraesentiert.
Sablotron gibts auch für Perl:
XML::Sablotron -> http://www.gingerall.cz/charlie-bin/get/webGA/act/xml-sab.actmal sehen, irgendwie muss mal anfangen mich mit XSLT zu beschaeftigen ;-))
Schade, ich dachte ich kann dir jetzt ein paar Expat-Tricks entlocken :-/
mit Expat direkt wuerde ich eh nicht arbeiten, das macht XML::Parser schon ;)
Die Transformation XML => Darstellung passiert mittel stinknormaler Templates (nix XSL, aus eben erwaehntem und Performancegruenden)
Ihr verzichtet aus Performance-Gründen auf XSL setzt aber DOM statt SAX ein?ja, u.a., DOM ist auch einfacher zu handlen (Zeitdruck bei der Entwicklung). Wie gesagt, die Teile, wo DOM nicht unbedingt notwendig ist, werden ueberarbeitet werden muessen.
Egal, vielleicht könntest du kurz mal umreissen wie das mit den templates funktioniert im Forum?
es gibt im Grossen und Ganzen drei Vorlagen, einmal fuer die Hauptdatei, fuer die Postinganzeige und fuer das Eingabeformular.
ein vorlage besteht aus einzelnen Schnipseln, welche angesprochen werden koennen und Platzhalter (Variablen quasi) enthalten koennen. Die Variablen koennen sowohl von der Applikation geliefert werden, als auch bereits im Template (als Schnipsel) stehen, wobei vom Programm gelieferte Variablen Vorrang haben.
Es gibt dann noch einige Goodies, wie IF-Bloecke und dergleichen. Includes fehlen noch, werden aber demnaechst eingebaut.Hmmm, jetzt hab ich wenigstens mal gesehen, wo diese vielsagenden Fehlermeldungen herkommen!
*gg*
bzw. was z.b. "{&& LINK_SELFAKTUELL &&}" zu bedeuten hat. Dient das nur als Markierungsstelle für eine Regexp, oder ist das irgendsoein durchgeknallter Perl-Trick?
hab ich schon erwaehnt, dass wir an der Doku arbeiten? ;-))
{&& LINK_SELFAKTUELL &&} ist ein Platzhalter (Templateintern in diesem Fall), {&& und &&} sind die Delimiter, die vom Regex erkannt werden. Dieser spezielle PLatzhalter zeigt auf einen Schnipsel, der nur den Link zu Selfaktuell enthaelt (und taucht mehrmals auf). Der Link selbst lagert also zentral und braucht so nur einmal geaendert werden (sollte das mal vorkommen)
Abgesehen davon scheint der Einsatz von XML für diese Templates doch mehr Modesklaverei, als Zusatznutzen zu sein ;-)
erwischt! ;)
Die Hauptdatei wird mit zwei fetten Regexps geparst (http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/selfforum/selfforum-cgi/shared/Posting/_lib.pm?rev=1.26&content-type=text%2Fvnd.viewcvs-markup&only_with_tag=HEAD, sub get_all_threads [nur, falls es dich interessiert ;)]).
*schluck* und ich dachte bisher, mit einem genügend dickem Zeitpolster könnte ich jede Perl-Datei (wenigstens) "lesen"!
*g* tip: von links nach rechts und von oben nach unten ;))
Viele Gruesse,
n.d.p.
-
Grüssi n.d.p!
wenn sie keine technischen Dokumente schreiben koennen, muessen sie halt jemanden bezahlen, der es kann *schulterzuck*
*g* das war ja bisher mein Job, nur begannen diese "technischen" Dokumente sich seit einiger zeit explosionsartig zu vermehren. Un da ich sehr faul bin, dachte ich, ich könnte da ein bissl was automatisieren ;-) Es ist also beabsichtigt, dass die Mitarbeiter _selbst_ ihre Dokumente schreiben.
Sablotron gibts auch für Perl:
XML::Sablotron -> http://www.gingerall.cz/charlie-bin/get/webGA/act/xml-sab.actmal sehen, irgendwie muss mal anfangen mich mit XSLT zu beschaeftigen ;-))
spannendes topic, kann ich dir sagen :-)
Schade, ich dachte ich kann dir jetzt ein paar Expat-Tricks entlocken :-/
mit Expat direkt wuerde ich eh nicht arbeiten, das macht XML::Parser schon ;)
Direkt wird ja eh nicht damit gearbeitet, ist ebenso wie XML::Parser nur ein modul, in dem Interfaces (zu Expat) zur Verfügung gestellt werden, die sogar so ähnlich heissen wie die im Nachbarhause bei Perl ;-)
hab ich schon erwaehnt, dass wir an der Doku arbeiten? ;-))
ja, vor ca. 3 monaten glaub ich ;-)
*SCNR*
*g* tip: von links nach rechts und von oben nach unten ;))
*lol*
lg bernhard
-
-
-
-
-
-
hallo,
- Wo ihr immer eure Sprüche her habt! Das war wiedermal ein grenzgenialer!
Von Herr Nietzsche, der mal meinte "Gott ist tot".
Was Gott nicht daran gehindert hat, am 25. August 1900 die Aussage "Nietzsche ist tot" zu treffen.Und spätestens seit es Austropop gibt weiss man auch in .de: "Gott ist eine Frau". Deshalb konnte Cheatah ja "sie" sagen ;-)
Grüße
Thomas
-
-
- Einfache Bedienung für die XML-Schreiberlinge
-
Hallo Bernhard!
Und ich schwanke dabei zwischen 2 Polen
Ich war mal in einer ähnlichen Situation. Nur, dass ich damals zwischen 2 Polinnen schwankte...
SCNR ;-)
Patrick
<hatehtehpehdoppelpunktslashslashwehwehwehpunktatomicminuseggspunktcomslash>-
Hallo Patrick,
Ich war mal in einer ähnlichen Situation. Nur, dass ich damals zwischen 2 Polinnen schwankte...
ich war auch schon immer für Emanzipation (+ Frauenbewegung ;)
Günter - Eisbär im Netz - mitfühlend ...
-
Hallo, Günter!
Moment, da ist erstmal ein kapitaler Fehler drin:
ich war auch schon immer für Emanzipation
das heisst Efrauzipation, gelle! Nichts verwechseln hier (Männer neigen ja häufig zu sowas, bedauerlicherweise).
(+ Frauenbewegung ;)
Das kann ich nun wieder verstehen - Männerbewegungen sind auch durchaus begrüssenswert. Nur leider so selten - und wenn, existiert gerade bei diesen Bewegungen häufig ein gewisses Rhythmusproblem.... ;o)
*scnr,t*
Stonie
-
Hi Stonie,
Moment, da ist erstmal ein kapitaler Fehler drin:
das heisst Efrauzipation, gelle! Nichts verwechseln hier (Männer neigen ja häufig zu sowas, bedauerlicherweise).stimmt, war zur sehr von meiner maskulinen Sicht geprägt *peinlein*
(+ Frauenbewegung ;)
Das kann ich nun wieder verstehen - Männerbewegungen sind auch durchaus begrüssenswert. Nur leider so selten - und wenn, existiert gerade bei diesen Bewegungen häufig ein gewisses Rhythmusproblem.... ;o)mhm, mein Rhythmusgefühl ? ... mhm naja ... durchwachsen, schätze ich mal ... <ausrede><small>Tagesform</small></ausrede> ...
Günter [alter Macho] - findet eFRAUzipation (mitunter||des öfteren) voll gut! ;)
-
-
-
Grüssi Patrick!
Und ich schwanke dabei zwischen 2 Polen
Ich war mal in einer ähnlichen Situation. Nur, dass ich damals zwischen 2 Polinnen schwankte...
Ich hoffe du bist nicht auch noch mit dem Kopf durch die Mauer gerannt?
;-)
lg bernhard
PS: Ausnahmsweise war ein Posting von mir zumindest einmal 100%ig ernst gemeint, und du - du schlimmer Finger - machst schon wieder eine Menschelei draus! *gggrrrrrr*
-
Hi Bernhard, hi Patrick,
Ich hoffe du bist nicht auch noch mit dem Kopf durch die Mauer gerannt?
Nein, das ist ausschließlich mein Zuständigkeitsbereich, und ich muss Euch sagen: versucht's nicht, es tut säuisch weh.
Grüße,
Utz
-
Hi,
Ich hoffe du bist nicht auch noch mit dem Kopf durch die Mauer gerannt?
Nein, das ist ausschließlich mein Zuständigkeitsbereich, und ich muss Euch sagen: versucht's nicht, es tut säuisch weh.
ich hab keinen Schimmer, wieso ich ausgerechnet jetzt darauf komme:
Liegt der Bauer auf der Lauer,
wird Herr Lauer ganz schön sauer!Cheatah ;-)
-
-
-
Hi Patrick, hi Bernhard,
Und ich schwanke dabei zwischen 2 Polen
Ich war mal in einer ähnlichen Situation. Nur, dass ich damals zwischen 2 Polinnen schwankte...
Meinst du etwa, der Bernhard ist andersrum "gepolt"? :-)
SCNR ;-)
ebenfalls :-)
MfG
Moldawian-
Hallo Moldawian!
Meinst du etwa, der Bernhard ist andersrum "gepolt"? :-)
Den Raum für Unterstellungen habe ich Dir ja überlassen ;-)
Patrick
<hatehtehpehdoppelpunktslashslashwehwehwehpunktatomicminuseggspunktcomslash>-
Grüssi,
Meinst du etwa, der Bernhard ist andersrum "gepolt"? :-)
Den Raum für Unterstellungen habe ich Dir ja überlassen ;-)nönö, ich kann euch beruhigen, bei mir ist alles richtigrum "gepolt".
Aber lasst das hier ja nicht ausarten, ich sags euch!lg bernhard
-
malzeit,
nönö, ich kann euch beruhigen, bei mir ist alles richtigrum "gepolt".
was ist richtig? (oder was ist normal?)
grüße
thomas-
malzeit,
Du speist zur Geisterstunde? Mutig!
nönö, ich kann euch beruhigen, bei mir ist alles richtigrum "gepolt".
was ist richtig? (oder was ist normal?)
War ne Anspielung auf das "andersrum" - Scheint als wären die "Anführungszeichen" auf das falsche Wort gerutscht ;-)
So, genug der kryptischen Postings!
lg bernhard
-
hi,
nönö, ich kann euch beruhigen, bei mir ist alles richtigrum "gepolt".
was ist richtig? (oder was ist normal?)
Für den Pragmatiker, das was die Mehrheit macht.
War ne Anspielung auf das "andersrum" - Scheint als wären die "Anführungszeichen" auf das falsche Wort gerutscht ;-)
Nee, nee wollte mit den Anführungszeichen das "gepolt" hervorheben, weil du und Patrick ja auch von Polen bzw. Polinnen spracht.
So, genug der kryptischen Postings!
Nur über meine Leiche ;-)
MfG
Moldawian
-
-
-
-
-
-
-
Hallo Bernhard,
Ich arbeite gerade an meiner ersten DTD (für einen Seminaranbieter). Und ich schwanke dabei zwischen 2 Polen:
- Einheitliches Erscheinungsbild
das hast du auf alle fälle: layout hat mit xml nichts zu tun.
- Einfache Bedienung für die XML-Schreiberlinge
das kannst du sowhl als auch haben, denn wie schon Cheatah sagte, dafür gibt's tools.
Da stehe ich an. Sollte man die DTD möglichst grosszügig gestalten, sodass die Verfasser selbst bestimmen können welche Werte ihre Attribute haben sollen,
hier würde ich eher strickt vorgehen: sollte später eine änderung nötig sein, ist es einfacher den attributwert freigeben, als umgekehrt (also alle mögliche vergebene werte zusammenzusuchen)
welche Elemente sie wo weglassen können, ...
das hängt ja auch von dir ab, wenn du elmenete als optionale elemente in der DTD definierst, können die autoren halten wie sie wollen.
oder sollte man ihnen eine (umfassende, vorher durchdiskutierte) begrenzte Menge an gültigen Werten, Elementen vorschreiben.
wäre ich dafür.
Gibts da einen Kompromiss, oder muss man das von Fall zu Fall selber abwägen, was nun gscheiter ist?
wenn ich dir "so locker wie möglich, aber so strikt wie nötig" sage ist dir nicht geholfen. ;-)
also ist immer eine frage der endanwendung, wie du deine dtd machst.Und thematisch dazupassend: Ist es überhaupt sinnvoll xml für nur leicht strukturierte Daten zu verwenden? Ich verwende derzeit eine ausgewählte Teilmenge von HTML-Elementen, und ein paar selbstdefinierte Container-Elemente, bzw. Metainformationen über die Datei selber.
ich habe das auch schon gemacht (für mittelkomplexe struktur), da habe ich eben aus gründen der autor-freundlichkeit z.B. eine etwas abgespeckte version des html-tabellenmodells verwendet.
(das rad wurde ja schon erfunden)und stattdessen gleich den ganzen HTML4-Standard in einem Namespace zu erlauben?
das würde ich nicht machen. html4 dtd ist nicht xml konform und würde dir auch davon abgesehen nur ärger bringen.
grüße
thomas-
Hi Thomas,
- Einheitliches Erscheinungsbild
das hast du auf alle fälle: layout hat mit xml nichts zu tun.
Layout im weiteren Sinne, ich meinte, dass jedes Seminar eine Detail-Beschreibung für z.b. "Seminarziel" hat, und nicht der eine hergeht, es "Seminarziel" nennt, der nächste glaubt es "Ihr Nutzen" nennen zu müssen, und wieder ein anderer meint für ihn wäre "Was sie lernen" am besten geeignet. Das meinte ich mit "Einheitliches Erscheinungsbild"
Aussehen sollte das ganze dann etwa so ähnlich wie derzeit:
http://www.wt-akademie.at/kurse/aus/ma/AbschlussAussageBUHA4.shtml- Einfache Bedienung für die XML-Schreiberlinge
das kannst du sowhl als auch haben, denn wie schon Cheatah sagte, dafür gibt's tools.
Die wir auch sicher verwenden werden! Wenn ich denen mit Meybohms HTML-Editor komme, schmeissen sie mich wahrscheinlich hochkant raus ... direkt in die Klappsmühle *g*
hier würde ich eher strickt vorgehen: sollte später eine änderung nötig sein, ist es einfacher den attributwert freigeben, als umgekehrt (also alle mögliche vergebene werte zusammenzusuchen)
Das ist ein gutes Argument, nur müsste ich da eine ganze Menge Attributwerte zulassen, denn jeder will was anderes haben. Die Firma ist - zu meinem (bereits mehrjährigem) Ärgernis - in ihrer Terminologie etwas chaotisch aufgebaut ;-) Mit einem Wort, ein Alptraum für den Versuch die Leistungen der Firma in ein strukturiertes oder normalisiertes Datenformat abzubilden :-(
welche Elemente sie wo weglassen können, ...
das hängt ja auch von dir ab, wenn du elmenete als optionale elemente in der DTD definierst, können die autoren halten wie sie wollen.
oder sollte man ihnen eine (umfassende, vorher durchdiskutierte) begrenzte Menge an gültigen Werten, Elementen vorschreiben.
wäre ich dafür.
hmmm
Gibts da einen Kompromiss, oder muss man das von Fall zu Fall selber abwägen, was nun gscheiter ist?
wenn ich dir "so locker wie möglich, aber so strikt wie nötig" sage ist dir nicht geholfen. ;-)
nö ;-)
ich habe das auch schon gemacht (für mittelkomplexe struktur), da habe ich eben aus gründen der autor-freundlichkeit z.B. eine etwas abgespeckte version des html-tabellenmodells verwendet.
(das rad wurde ja schon erfunden)naja, aber ca. 80% meiner DTD besteht aus Ersatzelementen für HTML-Elemente wie a,p,ul,ol,li,img,...
danke für deine Einschätzung,
bernhard - Einheitliches Erscheinungsbild