DTD: Elemente mit gemischtem Inhalt
Andreas Borutta
gegeben seien zwei Dokumente A und B:
A
<foo>Lorem
<bar>Ipsum</bar>
<bar>Doloret</bar>
</foo>
B
<foo>Lorem
<bar>Ipsum</bar>
</foo>
Die Absicht:
Zeicheninhalt in foo muss vorkommen.
Das Element bar in foo muss mindestens einmal vorkommen.
Somit sollen die Dokumente C und D ungültig sein:
C
<foo>
<bar>Ipsum</bar>
</foo>
D
<foo>Lorem</foo>
Laut den Angaben zur Notation für gemischten Inhalt auf
http://de.selfhtml.org/xml/dtd/elemente.htm#alternative_optionale
ist jedoch nur die Notation
| <!ELEMENT foo (#PCDATA | bar)*>
möglich.
Sie erlaubt jedoch C und D.
Kann man dann gar keine DTD formulieren, die nur A und B erlaubt?
Andreas
Martin Honnen
> Kann man dann gar keine DTD formulieren, die nur A und B erlaubt?
Nein, wenn ich http://www.w3.org/TR/xml/#sec-mixed-content richtig verstehe.
Mit der W3C-Schemasprache
(http://www.w3.org/TR/xmlschema-0/#mixedContent) kann man allerdings
<xs:element name="foo">
<xs:complexType mixed="true">
<xs:sequence>
<xs:element name="bar" type="xs:string"/>
</xs:sequence>
</xs:complexType>
</xs:element>
definieren, da ist das "foo"-Kindelement dann verpflichtend.
--
Martin Honnen
http://msmvps.com/blogs/martin_honnen/
Andreas Borutta
>> Kann man dann gar keine DTD formulieren, die nur A und B erlaubt?
>
> Nein, wenn ich http://www.w3.org/TR/xml/#sec-mixed-content richtig verstehe.
OK.
> Mit der W3C-Schemasprache
> (http://www.w3.org/TR/xmlschema-0/#mixedContent) kann man allerdings
>
> <xs:element name="foo">
> <xs:complexType mixed="true">
> <xs:sequence>
> <xs:element name="bar" type="xs:string"/>
> </xs:sequence>
> </xs:complexType>
> </xs:element>
>
> definieren, da ist das "foo"-Kindelement dann verpflichtend.
Danke für den Hinweis.
Also auch da offenbar keine Möglichkeit ein Element frei von
Zeicheninhalt zu verbieten. Hhmm.
Die Schemasprache empfinde ich als äußerst schlecht lesbar.
Mir ist DTD lieber.
Andreas
--
http://borumat.de
Wolfgang May
> Martin Honnen schrieb:
>
> >> Kann man dann gar keine DTD formulieren, die nur A und B erlaubt?
> >
> > Nein, wenn ich http://www.w3.org/TR/xml/#sec-mixed-content richtig verstehe.
>
> OK.
>
> > Mit der W3C-Schemasprache
> > (http://www.w3.org/TR/xmlschema-0/#mixedContent) kann man allerdings
> >
> > <xs:element name="foo">
> > <xs:complexType mixed="true">
> > <xs:sequence>
> > <xs:element name="bar" type="xs:string"/>
> > </xs:sequence>
> > </xs:complexType>
> > </xs:element>
> >
> > definieren, da ist das "foo"-Kindelement dann verpflichtend.
>
> Danke für den Hinweis.
> Also auch da offenbar keine Möglichkeit ein Element frei von
> Zeicheninhalt zu verbieten. Hhmm.
Doch, geht auch.
Du kannst mit xs:simpleType fast beliebige eigene atomare Datentypen
definieren. Also z.B. eine Einschraenkung von xs:string auf
Zeichenketten der Laenge mindestens 1:
<xs:simpleType name="nonemptystring">
<xs:restriction base="xs:string">
<xs:minLength value="1"/>
</xs:restriction>
</xs:simpleType>
Und das dann oben anstatt xs:string verwenden.
Genaueres findest Du in der Doku zu XML Schema Part 2: Datatypes
Uebersicht:
http://www.w3.org/TR/xmlschema-0/
Part II
http://www.w3.org/TR/xmlschema-2/
Ein paar einfache Beispiele zu einem running example findest Du
u.a. in meiner Vorlesung, unter
http://www.dbis.informatik.uni-goettingen.de/Lectures/
> Die Schemasprache empfinde ich als äußerst schlecht lesbar.
Aber dermassen ...
> Mir ist DTD lieber.
Schon, aber vieles geht damit halt nicht.
Ein weiterer Aspekt, wenn Du Software schreibst ist, dass es
DTD-validierende Tools wie Sand am Meer gibt, waehrend XML-Schema-faehige
eher selten (und nicht immer so vollstaendig/korrekt) sind.
Wolfgang
Andreas Borutta
[XML Schema Language]
>> Also auch da offenbar keine Möglichkeit ein Element frei von
>> Zeicheninhalt zu verbieten. Hhmm.
>
> Doch, geht auch.
> Du kannst mit xs:simpleType fast beliebige eigene atomare Datentypen
> definieren. Also z.B. eine Einschraenkung von xs:string auf
> Zeichenketten der Laenge mindestens 1:
>
> <xs:simpleType name="nonemptystring">
> <xs:restriction base="xs:string">
> <xs:minLength value="1"/>
> </xs:restriction>
> </xs:simpleType>
>
> Und das dann oben anstatt xs:string verwenden.
>
> Genaueres findest Du in der Doku zu XML Schema Part 2: Datatypes
>
> Uebersicht:
> http://www.w3.org/TR/xmlschema-0/
> Part II
> http://www.w3.org/TR/xmlschema-2/
>
> Ein paar einfache Beispiele zu einem running example findest Du
> u.a. in meiner Vorlesung, unter
> http://www.dbis.informatik.uni-goettingen.de/Lectures/
Danke für Deinen Hinweis.
Sobald man also detaillierte Vorschriften für den Inhalt von Elementen
(egal ob dies Zeicheninhalte oder Unterelemente betrifft) festlegen
will, kommt man offenbar nicht um den Einsatz der Schema-Sprache
herum.
>> Die Schemasprache empfinde ich als äußerst schlecht lesbar.
>
> Aber dermassen ...
>
>> Mir ist DTD lieber.
>
> Schon, aber vieles geht damit halt nicht.
> Ein weiterer Aspekt, wenn Du Software schreibst ist, dass es
> DTD-validierende Tools wie Sand am Meer gibt, waehrend XML-Schema-faehige
> eher selten (und nicht immer so vollstaendig/korrekt) sind.
Hhhmm.
Ich werde mich wohl erstmal mit den eingeschränkten Möglichkeiten der
DTD begnügen.
Sollte man - ganz allgemein gesprochen - eigentlich Konstruktionen wie
| <foo>Lorem
| <bar>Ipsum</bar>
| <bar>Doloret</bar>
| </foo>
lieber vermeiden und so einem "losen Zeicheninhalt" lieber ein Element
"verpassen"?
| <foo>
| <zot>Lorem</zot>
| <bar>Ipsum</bar>
| <bar>Doloret</bar>
| </foo>
Mir erschien die erste Variante eleganter, weil sie weniger Code
benötigt.
Auch im Hinblick auf praktische Gesichtspunkte beim Publizieren im Web
und dem Gestalten per CSS kommt man mit der ersten Variante recht
weit.
Andreas
Stefan Froehlich
> Sobald man also detaillierte Vorschriften für den Inhalt von Elementen
> (egal ob dies Zeicheninhalte oder Unterelemente betrifft) festlegen
> will, kommt man offenbar nicht um den Einsatz der Schema-Sprache
> herum.
Was ich mich entsinne, wurde die auch anno dazumal aus genau dem Grund
entwickelt, dass sich die DTDs als nicht ausreichend erwiesen haben.
Servus,
Stefan
--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike
Mit dem Duft der Natur - Stefan: rappeln, welch gesundes Begehren!
(Sloganizer)
Wolfgang May
Unterelemente gehen mit DTD doch sehr gut (zumindest content models,
die nicht Mixed Content haben):
<!ELEMENT foo (bla*, blubb, bar?, foo, bla)>
so etwa alles was mit regulaeren Ausdruecken spezifizierbar ist, geht da.
> festlegen
> will, kommt man offenbar nicht um den Einsatz der Schema-Sprache
> herum.
Die hauptsaechliche Schwaeche ist Textinhalt: DTD kennt nur PCDATA/CDATA.
Damit kann man ja nicht mal angeben, ob etwas numerisch oder alphanumerisch
sein soll.
Die meisten Anwendungen merken das. Java ja sowieso, weil
man die Daten in eine Variable binden muss. XPath/XQuery
hat eine Heuristik (z.B. Vergleich mit einer Zahlkonstanten
(Beispiel selbsterklaerend, aus der Vorlesung genommen)
//country[population > 1000000]).
Man kann sich aber in die Nesseln setzen wenn der zweite
Wert auch berechnet wird
//country[population > //country[@code='D']/population])
oder
for $c in //country
order by $c/population
... blabla ...
wird fuer den Benutzer ueberraschend alphanumerisch geordnet.
> > Schon, aber vieles geht damit halt nicht.
> > Ein weiterer Aspekt, wenn Du Software schreibst ist, dass es
> > DTD-validierende Tools wie Sand am Meer gibt, waehrend XML-Schema-faehige
> > eher selten (und nicht immer so vollstaendig/korrekt) sind.
>
> Hhhmm.
> Ich werde mich wohl erstmal mit den eingeschränkten Möglichkeiten der
> DTD begnügen.
Oft genuegt das ja. Wenn Du das Dokument mit Java (o.ae.) erstellst, kannst
Du ja die Bedingungen dort beim Erstellen pruefen; bzw umgekehrt bei
unbekannten Dokumenten beim Verarbeiten pruefen.
XML Schema stoesst auch in der Vorlesung auf wenig Gegenliebe und ist auch
schwer wirklich zu vermitteln. Ich belasse es meistens bei "Sie muessen wissen
dass es das gibt, und was es kann, falls Sie es mal brauchen - dann faengt
die Quaelerei an." Ohne Praxis und selbst herumbasteln geht da nicht viel
(schon weil es viel syntaktische Quaelerei ist), irgendwann geht es einem
dann leichter, aber immer noch laestig von der Hand.
Nuetzlich ist es uebrigens fuer JAXB, wenn man damit passende Java-Klassen
generieren lassen kann.
> Sollte man - ganz allgemein gesprochen - eigentlich Konstruktionen wie
>
> | <foo>Lorem
> | <bar>Ipsum</bar>
> | <bar>Doloret</bar>
> | </foo>
>
> lieber vermeiden und so einem "losen Zeicheninhalt" lieber ein Element
> "verpassen"?
>
> | <foo>
> | <zot>Lorem</zot>
> | <bar>Ipsum</bar>
> | <bar>Doloret</bar>
> | </foo>
>
> Mir erschien die erste Variante eleganter, weil sie weniger Code
> benötigt.
Glaubensfrage. Mixed contents ist pfui ;)
Nachteil: wenn Du auf Lorem zugreifen willst, vergleichen willst
etc kannst Du nur [foo/text() ='bla'] machen (und musst daran denken)
weil [foo='bla'] naemlich den Stringwert LoremIpsumDoloret ansetzen
wuerde, waehrend mit der zweiten Variante [foo/zot ='bla'] explizit
und klarer ist.
> Auch im Hinblick auf praktische Gesichtspunkte beim Publizieren im Web
> und dem Gestalten per CSS kommt man mit der ersten Variante recht
> weit.
Mit CSS kenne ich mich nicht wirklich aus.
Ich wuerde es nicht machen, weil man dann ein Stueck Text hat, was sich
nicht "positiv" und als ganzes von dem Restinhalt des Elements
selektieren laesst.
Ach ja, noch haesslicher wird es, wenn Du aus irgendeinem Grund mal
> | <foo><b>L</b>orem
> | <bar>Ipsum</bar>
> | <bar>Doloret</bar>
> | </foo>
oder sowas machen willst. Obige Selektion durch text() passt dann
naemlich nicht mehr, und Du wirst versuchen muessen, einen
Ausdruck fuer "gib mit den Inhalt des foo-Elements vor dem bar-Element"
zu finden.
Wolfgang
Wolfgang May
> On Sun, 05 Dec 2010 10:32:35 Andreas Borutta wrote:
> > Sobald man also detaillierte Vorschriften für den Inhalt von Elementen
> > (egal ob dies Zeicheninhalte oder Unterelemente betrifft) festlegen
> > will, kommt man offenbar nicht um den Einsatz der Schema-Sprache
> > herum.
>
> Was ich mich entsinne, wurde die auch anno dazumal aus genau dem Grund
> entwickelt, dass sich die DTDs als nicht ausreichend erwiesen haben.
Im Prinzip ja.
DTDs gabs ja schon lange mit SGML. Also dokumentorientiert, quasi
nur die Baumstruktur (d.h. ohne Betrachtung der Textinhalte)
beschreibend, ziemlich direkt mit regulaeren Ausdruecken verwandt und
einfach in effiziente Parser (Finite State Automata, lineare Laufzeit
bis auf den ID/IDREF-Check) umzusetzen.
Die Datenbankwelt wollte aber auch Datentypen (number, date, ...) haben
und musste so eine ganz andere Schiene aufmachen. Ableitung von
Datentypen, Integritaetsbedingungen an Wertebereiche, key/foreign-key
etc., was man so vom Datenbankschema eben kennt.
Ein Aspekt war auch, dass die DTD selber nicht in XML geschrieben ist
(sonst haette man vielleicht eine inkrementelle Erweiterung zu DTD
gemacht; so schwer waere das ja nicht gewesen - einfach statt
PCDATA/CDATA auch (SQL-)Datentypen erlauben und sich etwas zur
Definition von Datentypen ueberlegen).
Was dann zur XML-typischen Geschwaetzigkeit von XML Schema gefuehrt hat.
Die Grundkonzepte der Definition von XSD Simple Types (Ableitung,
facets) finden sich uebrigens auch bei RDF und OWL wieder und es ist dort
-von der Last der XML-Syntax befreit- auch relativ appetitlich
anzusehe (Syntax kann schon wieder etwas ueberholt sein, stabilisiert
sich aber irgendwann):
_:Longitude a rdfs:Datatype; owl:onDatatype xsd:decimal;
owl:withRestrictions (_:long1 _:long2).
_:long1 xsd:minInclusive -180 .
_:long2 xsd:maxInclusive 180 .
Wolfgang
Daniel Urban
[...]
> XML Schema stoesst auch in der Vorlesung auf wenig Gegenliebe und ist auch
> schwer wirklich zu vermitteln.
Kann ich absoult nicht nachvollziehen. Woran liegt es denn? Es ist doch
XML, was doch naheliegender ist.
> Ich belasse es meistens bei "Sie muessen wissen
> dass es das gibt, und was es kann, falls Sie es mal brauchen - dann faengt
> die Quaelerei an."
Welche Quälerei meinst Du denn? Ich musste mich ehrlich gesagt noch nicht
sonderlich quälen. Mittlerweile gibt es doch genügend gute Tools.
[...]
> Nuetzlich ist es uebrigens fuer JAXB, wenn man damit passende Java-Klassen
> generieren lassen kann.
Im Bereich Web-Services (WSDL) ist es notwendig. Geht das überhaupt mit
DTDs?
Gruß,
Daniel
Daniel Urban
> Andreas Borutta
>> Martin Honnen schrieb:
[...]
>> Die Schemasprache empfinde ich als äußerst schlecht lesbar.
>
> Aber dermassen ...
Was aber IMHO an XML liegt. Das ist immer schlecht lesbar, auch wenn immer
dafür geworben wird, dass es menschenlesbar sei.
>> Mir ist DTD lieber.
>
> Schon, aber vieles geht damit halt nicht.
> Ein weiterer Aspekt, wenn Du Software schreibst ist, dass es
> DTD-validierende Tools wie Sand am Meer gibt, waehrend XML-Schema-faehige
> eher selten (und nicht immer so vollstaendig/korrekt) sind.
Ist mir noch nicht wirklich aufgefallen. Die Tools die ich verwende, haben
mir bisher keinen Ärger gemacht. Mittlerweile dürfte die XSD wohl schon 10
oder mehr Jahre alt sein und die Tools dazu ausgereift sein.
Gruß,
Daniel
Wolfgang May
> "Wolfgang May"
> [...]
> > XML Schema stoesst auch in der Vorlesung auf wenig Gegenliebe und ist auch
> > schwer wirklich zu vermitteln.
>
> Kann ich absoult nicht nachvollziehen. Woran liegt es denn? Es ist doch
> XML, was doch naheliegender ist.
Es ist prinzipiell XML-Syntax, ja.
Der Punkt liegt in der Semantik, und der abgrundtiefen Umstaendlichkeit
von XML Schema um konzeptuell einfache Dinge auszudruecken.
Fuer Informatiker, die XML als Baumstruktur sehen koennen und wollen,
und mit Grammatiken und regulaeren Ausdruecken (hoffentlich) umgehen
koennen, ist es alles andere als naheliegend, einen regulaeren Ausdruck
erst langwierig durch eine kuenstliche Syntax zu beschreiben (waehrend
DTD fast genau regulaere Ausdrucke nutzt).
Natuerlich kann man sich auf den Standpunkt stellen, in der Vorlesung das
ganze Geraffel runterzubeten und sagen "und nun ist es bekannt". BWLer
werden das auch auswendig lernen und in der Klausur wieder aufzaehlen
koennen (ob sie es anwenden koennen moechte ich mal dahingestellt
lassen ...).
> > Ich belasse es meistens bei "Sie muessen wissen
> > dass es das gibt, und was es kann, falls Sie es mal brauchen - dann faengt
> > die Quaelerei an."
>
> Welche Quälerei meinst Du denn? Ich musste mich ehrlich gesagt noch nicht
> sonderlich quälen. Mittlerweile gibt es doch genügend gute Tools.
Das Zusammenklicken von irgendwas ist dem Verstaendnis von Konzepten
oft nicht foerderlich, und umgekehrt. Tools sind etwas was man IMHO
in Projekten verwenden kann, aber nicht in einer Vorlesung. Und auch
dann ist es eine Stufe umstaendlicher, sich erst zu ueberlegen was man
haben will, und das dann nochmal von hinten durch die Brust ins Auge
in die XML-Schema Begrifflichkeiten zu zerlegen.
> [...]
> > Nuetzlich ist es uebrigens fuer JAXB, wenn man damit passende Java-Klassen
> > generieren lassen kann.
>
> Im Bereich Web-Services (WSDL) ist es notwendig. Geht das überhaupt mit
> DTDs?
Kommt darauf an, ob Du auf die Konzepte von Web-Services rauswillst
(die boese gesagt nichts wesentlich anderes als das gute alte CORBA
plus ein bisschen webifying sind), oder auf die Programmierung. Die
Konzepte sind syntax-unabhaengig (und wenn man sie verstanden hat, hat
man auch gleich CORBA und den irgendwann kommenden Nachfolger von WSDL
& Co verstanden). Es macht IMHO wenig Sinn, (Uni-)Studierenden
vordergruendig die aktuell verwendete Syntax einzubleuen (mit der
koennen sie in Praktika, Projektarbeiten, Abschlussarbeiten
experimentieren), sondern sie sollen die Grundlagen und Konzepte
verstehen um ggf in Entwicklung und Forschung arbeiten zu koennen, und
auf jeden Fall auch im weiteren Berufsleben noch "neue" Entwicklungen
und Tendenzen darauf zurueckfuehren koennen.
Wolfgang
Wolfgang May
> "Wolfgang May"
> > Andreas Borutta
> >> Martin Honnen schrieb:
> [...]
> >> Die Schemasprache empfinde ich als äußerst schlecht lesbar.
> >
> > Aber dermassen ...
>
> Was aber IMHO an XML liegt. Das ist immer schlecht lesbar, auch wenn
> immer dafür geworben wird, dass es menschenlesbar sei.
Auch, ja. Aber bei XML Schema kommt dazu, dass es etwas einfaches und
bekanntes (regulaere Ausdruecke) durch ein kuenstliches (und separat
zu erlernendes und zu baendigendes) Sekundaervokabular beschreibt.
Die Kombination aus beidem vernebelt den Blick auf das eigentliche (im
worst case ueberlegt sich jemand nicht mal mehr die regulaeren
Ausdruecke, sondern hackt irgendwas in XSD runter, was dann mehr oder
weniger zufaellig irgendwie den Anforderungen genuegt. So wie es ja
auch Leute gibt, die ein Datenbankschema direkt auf den Tabellen
entwickeln anstatt erst eine konzeptuelles Modell zu machen; wenn sie
dann in Normalisierung nicht fit sind (was meistens der Fall ist)
kommen schlimme Ergebnisse raus).
Nicht umsonst hat die diskrete Mathematik und (theoretische) Informatik
in den 60ern-80ern formale Konzepte geschaffen, mit denen man
wichtige Dinge kurz und exakt beschreiben kann.
Dasselbe kann man natuerlich auch in XML (und RDF) "verbalisieren",
aber es wird dadurch nicht einfacher, sondern umstaendlicher und
damit fehleranfaelliger.
> >> Mir ist DTD lieber.
> >
> > Schon, aber vieles geht damit halt nicht.
> > Ein weiterer Aspekt, wenn Du Software schreibst ist, dass es
> > DTD-validierende Tools wie Sand am Meer gibt, waehrend XML-Schema-faehige
> > eher selten (und nicht immer so vollstaendig/korrekt) sind.
>
> Ist mir noch nicht wirklich aufgefallen. Die Tools die ich verwende, haben
> mir bisher keinen Ärger gemacht. Mittlerweile dürfte die XSD wohl schon 10
> oder mehr Jahre alt sein und die Tools dazu ausgereift sein.
Kommerzielle Tools sollten das hoffentlich sein. Da ich fuer die
universitaere Ausbildung und den Heimgebrauch aber nur
nicht-kommerzielle Versionen empfehlen kann, sehe ich die Situation da
deutlich eingeschraenkter.
Saxon, http://saxon.sourceforge.net/, um mal eines der IMHO
etabliertesten zu nennen, ist frei nur ohne XSD, und in der
kommerziellen Version mit XSD verfuegbar. Exist,
exist.sourceforge.net/, kam bei unserer letzten Installation
ueberhaupt nur mit DTDs zurecht. Oracle benutzt XML Schema wenn man
die Speicherung von XML-Dokumenten weiter optimieren und annotieren
will, war aber bei meinem letzten Versuch, es in die Vorlesung
einzubinden mit einigen Konstrukten so zickig, dass ich es verworfen
habe. IMHO sollte man sehr vorsichtig sein, bevor man sich auf XML
Schema festlegt.
Wolfgang
Daniel Urban
> Der Punkt liegt in der Semantik, und der abgrundtiefen Umstaendlichkeit
> von XML Schema um konzeptuell einfache Dinge auszudruecken.
> Fuer Informatiker, die XML als Baumstruktur sehen koennen und wollen,
> und mit Grammatiken und regulaeren Ausdruecken (hoffentlich) umgehen
> koennen, ist es alles andere als naheliegend, einen regulaeren Ausdruck
> erst langwierig durch eine kuenstliche Syntax zu beschreiben (waehrend
> DTD fast genau regulaere Ausdrucke nutzt).
XML ist umständlich, aber inhaltlich geht es um Typen. Das ist doch nicht
anders als in einer Programmiersprache. Die Typen werden definiert. Zwischen
den Typen gibt es Abhängigkeiten und Vererbung. Das sollte einem
Informatiker, der sich mit OOP auskennt, doch nicht so schwer fallen.
Reguläre Ausdrücke (als Syntax) sind meiner Meinung nach deutlich
schwieriger zu verstehen, was auch daran liegt, dass man diese in der
Entwicklung deutlich weniger oft benötigt. Zumindest ist das meine Erfahrung
aus der Praxis.
[...]
>> > Ich belasse es meistens bei "Sie muessen wissen
>> > dass es das gibt, und was es kann, falls Sie es mal brauchen - dann
>> > faengt
>> > die Quaelerei an."
>>
>> Welche Quälerei meinst Du denn? Ich musste mich ehrlich gesagt noch nicht
>> sonderlich quälen. Mittlerweile gibt es doch genügend gute Tools.
>
> Das Zusammenklicken von irgendwas ist dem Verstaendnis von Konzepten
> oft nicht foerderlich, und umgekehrt.
Das Tool soll auch nicht das Verständnis fördern, sondern die Arbeit
erleichtern. Das Verständnis muss man sich vorher aneignen.
> Tools sind etwas was man IMHO
> in Projekten verwenden kann, aber nicht in einer Vorlesung.
Richtig. Aber darum ging es mir auch gar nicht.
> Und auch
> dann ist es eine Stufe umstaendlicher, sich erst zu ueberlegen was man
> haben will, und das dann nochmal von hinten durch die Brust ins Auge
> in die XML-Schema Begrifflichkeiten zu zerlegen.
Das ist kein Problem von XSD, sondern ein grundsätzliches Problem, dass Du
Gedachtes in eine Sprache formulieren musst. Das sollte bei Java, C oder
Perl nicht anders sein.
>> [...]
>> > Nuetzlich ist es uebrigens fuer JAXB, wenn man damit passende
>> > Java-Klassen
>> > generieren lassen kann.
>>
>> Im Bereich Web-Services (WSDL) ist es notwendig. Geht das überhaupt mit
>> DTDs?
>
> Kommt darauf an, ob Du auf die Konzepte von Web-Services rauswillst
> (die boese gesagt nichts wesentlich anderes als das gute alte CORBA
> plus ein bisschen webifying sind), oder auf die Programmierung.
Es sollte wohl naheliegend gewesen sein, dass ich die Programmierung meinte.
Gruß,
Daniel
Daniel Urban
> Daniel Urban
>> Was aber IMHO an XML liegt. Das ist immer schlecht lesbar, auch wenn
>> immer dafür geworben wird, dass es menschenlesbar sei.
>
> Auch, ja. Aber bei XML Schema kommt dazu, dass es etwas einfaches und
> bekanntes (regulaere Ausdruecke) durch ein kuenstliches (und separat
> zu erlernendes und zu baendigendes) Sekundaervokabular beschreibt.
XSD beschreibt etwas einfaches und bekanntes: Objekte/Typen. Dies macht es
aufgrund der Umständlichkeit von XML entsprechend schlechter, als in einer
üblichen Programmiersprache. Ein Beispiel, wo noch mehr Programmierung in
XML gemacht wird, ist XSLT.
> Die Kombination aus beidem vernebelt den Blick auf das eigentliche (im
> worst case ueberlegt sich jemand nicht mal mehr die regulaeren
> Ausdruecke, sondern hackt irgendwas in XSD runter, was dann mehr oder
> weniger zufaellig irgendwie den Anforderungen genuegt.
Es geht auch in der Regel nicht um reguläre Ausdrücke, sondern um Typen und
Objekte. Du hast zum Beispiel auch JAX-B genannt, wo letztendlich nur von
einer "Programmiersprache" (XML) in die andere (Java) transformiert wird.
Bei Web-Services werden Werte mit bestimmten Typen verschickt.
Es geht also um Datenstrukturen, die mit geeigneter Syntax beschrieben
werden müssen. Dabei steht nicht die Syntax im Vordergrund, sondern der
Inhalt. Natürlich wäre es wünschenswert, wenn die Syntax nicht behindert.
[...]
>> Ist mir noch nicht wirklich aufgefallen. Die Tools die ich verwende,
>> haben
>> mir bisher keinen Ärger gemacht. Mittlerweile dürfte die XSD wohl schon
>> 10
>> oder mehr Jahre alt sein und die Tools dazu ausgereift sein.
>
> Kommerzielle Tools sollten das hoffentlich sein. Da ich fuer die
> universitaere Ausbildung und den Heimgebrauch aber nur
> nicht-kommerzielle Versionen empfehlen kann, sehe ich die Situation da
> deutlich eingeschraenkter.
Das ist natürlich eine unschöne Einschränkung. In der Praxis sollte diese
aber nicht gelten.
> IMHO sollte man sehr vorsichtig sein, bevor man sich auf XML
> Schema festlegt.
Man wird in der Praxis oftmals gar keine andere Wahl haben.
Gruß,
Daniel
Wolfgang May
> "Wolfgang May"
> > Daniel Urban <urba...@cs.tu-berlin.de> wrote:
> >> "Wolfgang May"
> [...]
> > Es ist prinzipiell XML-Syntax, ja.
> > Der Punkt liegt in der Semantik, und der abgrundtiefen Umstaendlichkeit
> > von XML Schema um konzeptuell einfache Dinge auszudruecken.
> > Fuer Informatiker, die XML als Baumstruktur sehen koennen und wollen,
> > und mit Grammatiken und regulaeren Ausdruecken (hoffentlich) umgehen
> > koennen, ist es alles andere als naheliegend, einen regulaeren Ausdruck
> > erst langwierig durch eine kuenstliche Syntax zu beschreiben (waehrend
> > DTD fast genau regulaere Ausdrucke nutzt).
>
> XML ist umständlich, aber inhaltlich geht es um Typen.
Eigentlich eben nicht. Es geht um Strukturen. Um Baeume.
> Das ist doch nicht
> anders als in einer Programmiersprache. Die Typen werden definiert. Zwischen
> den Typen gibt es Abhängigkeiten und Vererbung. Das sollte einem
> Informatiker, der sich mit OOP auskennt, doch nicht so schwer fallen.
>
> Reguläre Ausdrücke (als Syntax) sind meiner Meinung nach deutlich
> schwieriger zu verstehen, was auch daran liegt, dass man diese in der
> Entwicklung deutlich weniger oft benötigt. Zumindest ist das meine Erfahrung
> aus der Praxis.
Natuerlich gibt es Leute, die die Ergebnisse aus 50 Jahren
theoretischer Informatik fuer ueberfluessig und laestig halten.
Meistens sieht man es deren Software"loesungen" auch an.
Der OP sieht auch DTDs als das intuitivere an.
> Das ist kein Problem von XSD, sondern ein grundsätzliches Problem, dass Du
> Gedachtes in eine Sprache formulieren musst. Das sollte bei Java, C oder
> Perl nicht anders sein.
In den genannten Programmiersprachen formuliert man einen inhaerent
imperativen Algorithmus in einer dafuer geeigneten Programmiersprache
(fuer Faelle wo andere Programmierparadigmen besser geeignet sind gibt
es aber ja auch entsprechend andere Programmiersprachen). XSD ist aber eben
nicht der geeignetste Formalismus, um Baumstrukturen zu beschreiben.
> >> [...]
> >> > Nuetzlich ist es uebrigens fuer JAXB, wenn man damit passende
> >> > Java-Klassen
> >> > generieren lassen kann.
> >>
> >> Im Bereich Web-Services (WSDL) ist es notwendig. Geht das überhaupt mit
> >> DTDs?
> >
> > Kommt darauf an, ob Du auf die Konzepte von Web-Services rauswillst
> > (die boese gesagt nichts wesentlich anderes als das gute alte CORBA
> > plus ein bisschen webifying sind), oder auf die Programmierung.
>
> Es sollte wohl naheliegend gewesen sein, dass ich die Programmierung meinte.
Programmierung ohne Verstaendnis halte ich fuer riskant und im
Ergebnis oft qualitativ minderwertig. Mit Konzeptverstaendnis
kann man sich -mit ggf allerdings durchaus hohem Aufwand- in jedes
Tool reinfuchsen.
Wolfgang
Wolfgang May
> "Wolfgang May"
> > Daniel Urban
> >> Was aber IMHO an XML liegt. Das ist immer schlecht lesbar, auch wenn
> >> immer dafür geworben wird, dass es menschenlesbar sei.
> >
> > Auch, ja. Aber bei XML Schema kommt dazu, dass es etwas einfaches und
> > bekanntes (regulaere Ausdruecke) durch ein kuenstliches (und separat
> > zu erlernendes und zu baendigendes) Sekundaervokabular beschreibt.
>
> XSD beschreibt etwas einfaches und bekanntes: Objekte/Typen.
Was aber nicht unbedingt zu den Konzepten XML passt.
Natuerlich kann man alles als Typen sehen, es ist aber oft eben nicht
die intuitivste (und damit am wenigsten fehleranfaellige) Art.
> Dies macht es
> aufgrund der Umständlichkeit von XML entsprechend schlechter, als in einer
> üblichen Programmiersprache. Ein Beispiel, wo noch mehr Programmierung in
> XML gemacht wird, ist XSLT.
>
> > Die Kombination aus beidem vernebelt den Blick auf das eigentliche (im
> > worst case ueberlegt sich jemand nicht mal mehr die regulaeren
> > Ausdruecke, sondern hackt irgendwas in XSD runter, was dann mehr oder
> > weniger zufaellig irgendwie den Anforderungen genuegt.
>
> Es geht auch in der Regel nicht um reguläre Ausdrücke, sondern um Typen und
> Objekte. Du hast zum Beispiel auch JAX-B genannt, wo letztendlich nur von
> einer "Programmiersprache" (XML) in die andere (Java) transformiert wird.
> Bei Web-Services werden Werte mit bestimmten Typen verschickt.
Das was man in JAXB verwendet ist eine kleine Untermenge dessen was
XML umfasst. Im wesentlichen naemlich genau das was es seit Urzeiten
als Records, bzw. in Wissensrepraesentation als Slotted Frames
bezeichnet gibt. So wie komplexere Unterstrukturen abzubilden sind,
wird XSD und der Umgang mit den von JAXB generierten Klassen (durch
eigentlich ueberfluessige Schachtelung von Kollektionen) extremst
umstaendlich. Da merkt man dann, dass man eben nicht auf Typen,
sondern auf irgendwas, das als XML-Baum codiert ist und zwanghaft
mit den Mitteln generischer Typen behandelt werden muss
(Fuer <Bib><Book>...</Book><Book>...</Book>...</Bib>
bekommt man mit a_bib.getBook() nicht etwa eine Instanz von Book,
sondern eine Collection mit der man dann noch herumnudeln muss.)
> Es geht also um Datenstrukturen, die mit geeigneter Syntax beschrieben
> werden müssen.
Zuerst mal geht es um spezielle Datenstrukturen: Baeume. Und fuer die
gibt es an sich besser geeignete, spezielle Formalismen.
> > Kommerzielle Tools sollten das hoffentlich sein. Da ich fuer die
> > universitaere Ausbildung und den Heimgebrauch aber nur
> > nicht-kommerzielle Versionen empfehlen kann, sehe ich die Situation da
> > deutlich eingeschraenkter.
>
> Das ist natürlich eine unschöne Einschränkung. In der Praxis sollte diese
> aber nicht gelten.
Fuer die meisten kleineren Projekte -und viele, die auf XML arbeiten
sind solche- gilt sie.
> > IMHO sollte man sehr vorsichtig sein, bevor man sich auf XML
> > Schema festlegt.
>
> Man wird in der Praxis oftmals gar keine andere Wahl haben.
Dann muss man es natuerlich.
Wolfgang
Andreas Borutta
> XML Schema stoesst auch in der Vorlesung auf wenig Gegenliebe und ist auch
> schwer wirklich zu vermitteln. Ich belasse es meistens bei "Sie muessen wissen
> dass es das gibt, und was es kann, falls Sie es mal brauchen - dann faengt
> die Quaelerei an." Ohne Praxis und selbst herumbasteln geht da nicht viel
> (schon weil es viel syntaktische Quaelerei ist), irgendwann geht es einem
> dann leichter, aber immer noch laestig von der Hand.
Ich möchte Deine Bewertung ("syntaktische Quälerei") aufgreifen und
sie als Ausgangspunkt für eine Bitte um eine Empfehlung zu einem
anderen Thema verwenden.
Insgesamt schätze ich es sehr, wenn neben sachlichen Infos auch
subjektive Wertungen mit einfließen. Das erleichtert die
Experimentierphase, weil man eine Ahnung vom "Geschmack" (genauer: vom
Geschmacksempfinden erfahrener Programierer) erhält.
Welche Aufgaben interessieren mich zunächst vorrangig?
XHTML-Dokumente (später auch XML) sollen gezielt verändert, gekürzt,
anreichert werden.
Die Programmiersprache soll auf dem Server einsetzbar sein, gut (für
Menschen) lesbar und wartbar sein und einen direkten gezielten Zugriff
auf spezifische Elemente, deren Attribute und deren Zeicheninhalte
bieten.
Der Zugriff soll explizit nicht über die Suche nach Zeichenketten via
RegEx laufen, sondern es soll die Struktur des Dokumentes verwendet
werden können.
Ein Beispiel für eine typische Manipulations-Aufgabe steht unten.
Bisher habe ich mich praktisch noch gar nicht mit Programmierung
beschäftigt.
Wenn ich es richtig verstehe, beherrschen viele Sprachen den Zugriff
auf die Elemente. Python, Ruby, Perl, PHP, XSLT
Bei PHP, zum Beispiel, scheint das jedoch kaum jemand zu verwenden.
Aber das nur am Rande.
Von Daniel Mölle las ich in einem Artikel:
"Eine wesentliche Vorraussetzung für gute Architekturen ist und bleibt
jenseits aller Strömungen das korrekte Verständnis der Domäne, also
einmal mehr das Erkennen der Natur der zu lösenden Aufgabe. [...] die
elegantesten Lösungen genau dann entstehen, wenn sie die dem
untersuchten Problem zugrunde liegende Struktur präzise erfassen und
in der Software ohne künstlichen Ballast wiedergeben.
[...]
Als einzig vielversprechender Weg bleibt die Verwendung solcher
Prozessmodelle, die sich hinsichtlicher ihrer Komplexität auf das
jeweilige Projekt zuschneiden lassen [...]"
XSLT macht wie XML-Schema den Eindruck, dass damit zwar komplexe
Aufgaben lösbar sind, jedoch der Code sehr schlecht lesbar ist und
möglicherweise daher der Natur weniger komplexer Aufgaben nicht
angemessen ist.
Ich freue mich über Eure Empfehlungen und Sichtweisen.
Andreas
Beispiel:
Es gibt eine Sitemap als verschachtelte Liste.
| <ul id="sitemap">
| <li><a href="/">Startseite</a></li>
| <li><a href="/thema-1/">Thema 1</a>
| <ul>
| <li><a href="/thema-1/thema-1.1/">Thema 1.1</a></li>
| <li><a href="/thema-1/thema-1.2/">Thema 1.2</a></li>
| </ul>
| </li>
| <li><a href="/thema-2/">Thema 2</a>
| <ul>
| <li><a href="/thema-2/thema-2.1/">Thema 2.1</a>
| <ul>
| <li><a href="/thema-2/thema-2.1/thema-2.1.1/">Thema 2.1.1</a></li>
| <li><a href="/thema-2/thema-2.1/thema-2.1.2/">Thema 2.1.2</a></li>
| <li><a href="/thema-2/thema-2.1/thema-2.1.3/">Thema 2.1.3</a></li>
| </ul>
| </li>
| <li><a href="/thema-2/thema-2.2/">Thema 2.2</a></li>
| </ul>
| </li>
| </ul>
Auf der Seite "/thema-2/thema-2.1/thema-2.1.2/" soll Folgendes
ausgeliefert werden:
| <div id="nav-main">
| <ul>
| <li><a href="/">Startseite</a></li>
| <li><a href="/thema-1/">Thema 1</a></li>
| <li><a href="/thema-2/"><strong>Thema 2</strong></a></li>
| </ul>
| </div>
| <div id="nav-detail">
| <ul>
| <li><a href="/thema-2/thema-2.1/"><strong>Thema 2.1</strong></a>
| <ul>
| <li><a href="/thema-2/thema-2.1/thema-2.1.1">Thema 2.1.1</a></li>
| <li id="current"><strong>Thema 2.1.2</strong></li>
| <li><a href="/thema-2/thema-2.1/thema-2.1.3">Thema 2.1.3</a></li>
| </ul>
| </li>
| <li><a href="/thema-2/thema-2.2/">Thema 2.2</a></li>
| </ul>
| </div>
Später soll XML und nicht mehr XHTML als Quelle für die Navigation
dienen:
| <sitemap title="Lorem Ipsum">
| <item dir="thema-1" title="Thema 1">
| <item dir="thema-1.1" title="Thema 1.1"/>
| <item dir="thema-1.2" title="Thema 1.2"/>
| </item>
| <item dir="thema-2" title="Thema 2">
| <item dir="thema-2.1" title="Thema 2.1">
| <item dir="thema-2.1.1" title="Thema 2.1.1"/>
| <item dir="thema-2.1.2" title="Thema 2.1.2"/>
| <item dir="thema-2.1.1" title="Thema 2.1.3"/>
| </item>
| <item dir="thema-2.2" title="Thema 2.2"/>
| </item>
| </sitemap>
Wolfgang May
> Wolfgang May schrieb:
>
> > XML Schema stoesst auch in der Vorlesung auf wenig Gegenliebe und ist auch
> > schwer wirklich zu vermitteln. Ich belasse es meistens bei "Sie muessen wissen
> > dass es das gibt, und was es kann, falls Sie es mal brauchen - dann faengt
> > die Quaelerei an." Ohne Praxis und selbst herumbasteln geht da nicht viel
> > (schon weil es viel syntaktische Quaelerei ist), irgendwann geht es einem
> > dann leichter, aber immer noch laestig von der Hand.
>
> Ich möchte Deine Bewertung ("syntaktische Quälerei") aufgreifen und
> sie als Ausgangspunkt für eine Bitte um eine Empfehlung zu einem
> anderen Thema verwenden.
>
> Insgesamt schätze ich es sehr, wenn neben sachlichen Infos auch
> subjektive Wertungen mit einfließen. Das erleichtert die
> Experimentierphase, weil man eine Ahnung vom "Geschmack" (genauer: vom
> Geschmacksempfinden erfahrener Programierer) erhält.
>
> Welche Aufgaben interessieren mich zunächst vorrangig?
>
> XHTML-Dokumente (später auch XML) sollen gezielt verändert, gekürzt,
> anreichert werden.
XSLT, XQuery, oder - mit Einschraenkungen XML Query mit Updates (das
ist etwas anderes als XML:DB's XUpdate, was es auch gibt, aber eher
mit XSLT verwandt ist, in 1999/2000 entwickelt wurde, dann eingestellt
wurde, und und eher selten ist; z.B. der eXist Server verwendete es).
Eine Frage ist dabei: willst Du das Ausgangsdokument behalten und
ausserdem ein neues Dokument haben (XQuery, XSLT) , oder soll das
Ausgangsdokument ersetzt werden (XQuery+Updates, aber auch XSLT
oder XQuery und dann Ergebnis drueberkopieren)?
> Die Programmiersprache soll auf dem Server einsetzbar sein, gut (für
> Menschen) lesbar und wartbar sein und einen direkten gezielten Zugriff
> auf spezifische Elemente, deren Attribute und deren Zeicheninhalte
> bieten.
> Der Zugriff soll explizit nicht über die Suche nach Zeichenketten via
> RegEx laufen, sondern es soll die Struktur des Dokumentes verwendet
> werden können.
>
> Ein Beispiel für eine typische Manipulations-Aufgabe steht unten.
>
> Bisher habe ich mich praktisch noch gar nicht mit Programmierung
> beschäftigt.
>
> Wenn ich es richtig verstehe, beherrschen viele Sprachen den Zugriff
> auf die Elemente. Python, Ruby, Perl, PHP, XSLT
Der primaere Unterschied zwischen den ersten 4 und XSLT (und
XPath/XQuery) ist, dass die ersten allgemeine (imperative, bzw
objektorientiert mit imperativem Kern) Programmiersprache sind, die
auf Datenstrukturen (die zufaellig ein XML-Dokument sind) im
wesentlichen "einzelschrittig" arbeiten, waehrend die anderen die
speziellen Eigenschaften von XML nutzen (und funktional bzw.
funktional-regelbasiert sind, als "deklarativ" bezeichnet werden).
Meistens ist Code in Query oder XSLT erheblich kuerzer (und damit
uebersichtlicher, wartbarer, weniger fehlerintensiv) als in
einer der allgemeinen Programmiersprachen, weil Navigation und Iteration
und tlw. auch Fallunterscheidung built-in in die Semantik der Sprache
sind.
[umgekehrt wuerde man z.B. einen Graphenalgorithmus, Shortest paths
oder sowas, dessen Eingabegraph "zufaellig" als XML-Dokument
daherkommt, nicht in XSLT oder XQuery machen, sondern in
Java/Perl/sonstwas. Es geht aber auch in XQuery (fuer
Functional-Programming-Freaks kein Problem) und auch in XSLT (was ich
fuer diesen Fall als etwas pervers bezeichnen wuerde)].
> Bei PHP, zum Beispiel, scheint das jedoch kaum jemand zu verwenden.
> Aber das nur am Rande.
>
> Von Daniel Mölle las ich in einem Artikel:
>
> "Eine wesentliche Vorraussetzung für gute Architekturen ist und bleibt
> jenseits aller Strömungen das korrekte Verständnis der Domäne, also
> einmal mehr das Erkennen der Natur der zu lösenden Aufgabe. [...] die
> elegantesten Lösungen genau dann entstehen, wenn sie die dem
> untersuchten Problem zugrunde liegende Struktur präzise erfassen und
> in der Software ohne künstlichen Ballast wiedergeben.
Das trifft es exakt. Und damit eben auch den Punkt, ob man auf einer
Baumstruktur eben oft besser mit passenden Paradigmen (=funktional
(XQuery), funktional-regelbasiert (XSLT) und/oder mit Navigation (XPath))
rangeht, als alles in Java und prozedural-einzelschrittig zu
verpacken.
XQuery als Anfragesprache ist stabil. Man kann es aber nicht nur als
"klassische" Anfragesprache verwenden, sondern damit im return-Teil
und durch Subqueries im return-Teil auch XML-Strukturen (und prinzipiell
auch beliebiges anderes) konstruieren und ausgeben.
Wenn Du XQuery kannst, und XSLT nicht, ist XQuery sicher der schnellere
Weg um etwas jetzt umzusetzen - XSLT bei Gelegenheit mal anschauen
schadet aber dann nicht.
> [...]
> Als einzig vielversprechender Weg bleibt die Verwendung solcher
> Prozessmodelle, die sich hinsichtlicher ihrer Komplexität auf das
> jeweilige Projekt zuschneiden lassen [...]"
>
> XSLT macht wie XML-Schema den Eindruck, dass damit zwar komplexe
> Aufgaben lösbar sind, jedoch der Code sehr schlecht lesbar ist und
> möglicherweise daher der Natur weniger komplexer Aufgaben nicht
> angemessen ist.
Das kommt darauf an, in welcher Weise die Aufgabe komplex ist. XSLT
und XML Schema (oft auch als XSD bezeichnet; falls die synonyme
Benutzung dieser beiden Begriffe/Akronyme Dich irgendwie verwirren
sollte) haben gemeinsam, dass beide etwas in XML ausdruecken. Soweit,
so geschwaetzig. Der Unterschied -IMHO- ist, dass XSD dabei aber auch
konzeptuell nicht die naheliegendste Loesung ist (und damit doppelt
laestig). Bei XSLT ist es anders: das was es beschreibt, ist sehr gut
so beschreibbar; zwar etwas geschwaetzig, aber konzeptuell sehr
treffend. Andererseits ist XSLT von Art des Denkens und des Ablaufs
gewoehnungsbeduerftig - wenn man es aber mal raus hat, ist es fuer
viele Probleme optimalst und knackig kurz und uebersichtlich (weil es
etwas "anders" ist). Grob: wenn man gut die Baumstruktur nutzen kann,
und "regelbasiert" ein Element lokal betrachten und behandeln
(umformen und das Ergebnis in den Output haengen) kann, ist XSLT sehr
geeignet. Es gibt aber auch Dinge, wo es schmerzhaft wird, und man
zuviel prozedurales ins funktionale reintricksen muss, um etwas halt
noch irgendwie in XSLT machen zu koennen. Fuer die eher einfachen
Dinge wie in Deinem Beispiel ist es sehr einfach (aber XQuery auch).
XSLT zu lernen und begreifen erfordert zuerst einiges an
Experimentieren um ein Feeling dafuer zu bekommen (es gibt auch Leute,
denen das sehr schwerfaellt). Einen grossen Vorteil von XSLT
gegenueber XQuery hat man, wenn die Struktur des Baumes flexibel ist,
und man etwa "Du bist jetzt auf einem Element, mache mit den
Attributen folgendes, und laufe dann mal rekursiv ueber alle
Unterelemente und mache 'das passende', egal was das Element fuer
einen Typ hat" machen will. Die Fallunterscheidung, was dann zu tun
ist, uebernimmt XSLT selbstaendig und sucht sich das richtige Template
(=Abbildungsregel) raus. Wartbar- und Erweiterbarkeit ist auch relativ
einfach, weil man einzelne Templates jederzeit aendern oder
hinzunehmen kann.
Beispiele zu beidem, auch gegeneinander gestellt findest Du in dem
genannten Foliensatz, der soll ja den Studierenden nahebringen wo
die Geheimnisse liegen.
Zu XQuery wurde in den letzten Jahren noch eine Update Facility
entwickelt, das inzwischen Candidate Recommendation ist, und damit
als ziemlichst stabil anzusehen ist:
http://www.w3.org/TR/xquery-update-10/
Manche Tools implementieren es:
Saxon mit Beispielen:
http://www.xmlplease.com/xquery-update
Exist hat es auch,
http://exist.sourceforge.net/update_ext.html
Oracle ist auch dran (genauen Status weiss ich nicht; falls es
im SS2011 eine XML-Vorlesung gibt werde ich mir das mal anschauen ...)
http://nativexmldatabase.com/2008/09/30/xml-in-oracle-11g/
http://download.oracle.com/docs/cd/E17276_01/html/gsg_xml/cxx/modifydocument.html
Kann man sich ueberlegen, weil man damit sozusagen direkt in den Baum
reinschiessen kann, waehrend XQuery und XSLT neu konstruieren. Wenn
das auf einer DB laeuft (oracle, exist z.B.; saxon nicht), wird das irgendwann
zum *Veraendern* des Baumes mal am effizientesten sein.
Wolf*14:15 DB-Vorlesung*gang
Andreas Borutta
Erstmal herzlichen Dank für Deine sehr ausführliche Antwort.
>> Welche Aufgaben interessieren mich zunächst vorrangig?
>>
>> XHTML-Dokumente (später auch XML) sollen gezielt verändert, gekürzt,
>> anreichert werden.
>
> XSLT, XQuery, oder - mit Einschraenkungen XML Query mit Updates (das
> ist etwas anderes als XML:DB's XUpdate, was es auch gibt, aber eher
> mit XSLT verwandt ist, in 1999/2000 entwickelt wurde, dann eingestellt
> wurde, und und eher selten ist; z.B. der eXist Server verwendete es).
>
> Eine Frage ist dabei: willst Du das Ausgangsdokument behalten und
> ausserdem ein neues Dokument haben (XQuery, XSLT) ,
Genau das.
Wobei das "neue" Dokument nur auf Anfrage erzeugt wird. (Es wird
allenfalls, wenn nötig, aus Performancegründen, in einem Cache
abgelegt.) Der Charakter des neuen Dokumentes soll flüchtig sein.
Anders ausgedrückt:
Alles was von Dauer ist, Struktur und Semantik des Kerninhaltes
(Artikels), wird im Dokument abgelegt.
Der ganze andere Schlunz wie Navi, Suchfunktion, etc. aber auch die
Kopfdaten, die zu den gerade aktuellen Clients passen - all das soll
völlig davon abgetrennt sein.
Eine andere wesentliche architektonische Frage, ob die Inhalte in
einer Datenbank oder "nur" in der Verzeichnisstruktur liegen, die
möchte ich in diesem Thread bewußt ausklammern.
[...]
>> Wenn ich es richtig verstehe, beherrschen viele Sprachen den Zugriff
>> auf die Elemente. Python, Ruby, Perl, PHP, XSLT
[...]
>> XSLT macht wie XML-Schema den Eindruck, dass damit zwar komplexe
>> Aufgaben lösbar sind, jedoch der Code sehr schlecht lesbar ist und
>> möglicherweise daher der Natur weniger komplexer Aufgaben nicht
>> angemessen ist.
>
> Das kommt darauf an, in welcher Weise die Aufgabe komplex ist. XSLT
> und XML Schema (oft auch als XSD bezeichnet; falls die synonyme
> Benutzung dieser beiden Begriffe/Akronyme Dich irgendwie verwirren
> sollte) haben gemeinsam, dass beide etwas in XML ausdruecken. Soweit,
> so geschwaetzig. Der Unterschied -IMHO- ist, dass XSD dabei aber auch
> konzeptuell nicht die naheliegendste Loesung ist (und damit doppelt
> laestig). Bei XSLT ist es anders: das was es beschreibt, ist sehr gut
> so beschreibbar; zwar etwas geschwaetzig, aber konzeptuell sehr
> treffend. Andererseits ist XSLT von Art des Denkens und des Ablaufs
> gewoehnungsbeduerftig - wenn man es aber mal raus hat, ist es fuer
> viele Probleme optimalst und knackig kurz und uebersichtlich (weil es
> etwas "anders" ist). Grob: wenn man gut die Baumstruktur nutzen kann,
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Das sollte der Fall sein, da es um wohlgeformtes und valides XML geht.
> und "regelbasiert" ein Element lokal betrachten und behandeln
> (umformen und das Ergebnis in den Output haengen) kann,
Hier ist mir noch klar, was Du damit genau meinst.
> ist XSLT sehr
> geeignet. Es gibt aber auch Dinge, wo es schmerzhaft wird, und man
> zuviel prozedurales ins funktionale reintricksen muss, um etwas halt
> noch irgendwie in XSLT machen zu koennen.
Ist dies der Grund, warum in verbreiteten Architekturen, wo es ums
Publizieren geht, wie z.B. Wordpress oder Joomla XSLT nicht verwendet
wird?
[...]
> Zu XQuery wurde in den letzten Jahren noch eine Update Facility
> entwickelt, das inzwischen Candidate Recommendation ist, und damit
> als ziemlichst stabil anzusehen ist:
> http://www.w3.org/TR/xquery-update-10/
> Manche Tools implementieren es:
> Saxon mit Beispielen:
> http://www.xmlplease.com/xquery-update
> Exist hat es auch,
> http://exist.sourceforge.net/update_ext.html
> Oracle ist auch dran (genauen Status weiss ich nicht; falls es
> im SS2011 eine XML-Vorlesung gibt werde ich mir das mal anschauen ...)
> http://nativexmldatabase.com/2008/09/30/xml-in-oracle-11g/
> http://download.oracle.com/docs/cd/E17276_01/html/gsg_xml/cxx/modifydocument.html
>
> Kann man sich ueberlegen, weil man damit sozusagen direkt in den Baum
> reinschiessen kann, waehrend XQuery und XSLT neu konstruieren. Wenn
> das auf einer DB laeuft (oracle, exist z.B.; saxon nicht), wird das irgendwann
> zum *Veraendern* des Baumes mal am effizientesten sein.
Danke für all die Hinweise.
Wenn ich alles richtig verstanden habe, empfiehlst Du deutlich die
Verwendung von XSLT/XQuery und rätst von den allgemeinen
Programmiersprachen - für die skizzierten Aufgaben - ab.
Andreas
Daniel Urban
> Wolfgang May schrieb:
[...]
> XSLT macht wie XML-Schema den Eindruck, dass damit zwar komplexe
> Aufgaben lösbar sind, jedoch der Code sehr schlecht lesbar ist und
> möglicherweise daher der Natur weniger komplexer Aufgaben nicht
> angemessen ist.
Meiner Meinung nach sollte man es vermeiden, in XML zu programmieren. Ich
habe vor einigen Jahren mal sehr intensiv mit XSLT programmiert und kann nur
davon abraten. Es ist aufgeblasen, für einen Entwickler auch eher
unleserlich und meisten auch noch recht schlecht in der Performance.
Allerdings kann man sich schon Anwendugsfälle vorstellen, wo XSLT vielleicht
Sinn macht.
Andere Tools haben aber sicher auch ihre Probleme, weswegen man sich die
Dinge genau anschauen sollte. Ich würde zum Beispiel ungern mit der
offiziellen DOM API in Java arbeiten. Diese ist umständlich, wenig
performant und auch noch sehr speicherintensiv. Zumindestens war es damals
so.
Gruß,
Daniel
Andreas Borutta
Was wäre denn heute Dein Mittel der Wahl um in XML ausgezeichnete
Artikel gezielt zu manipulieren?
Andreas
Daniel Urban
> Daniel Urban
[...]
>> XML ist umständlich, aber inhaltlich geht es um Typen.
>
> Eigentlich eben nicht. Es geht um Strukturen. Um Baeume.
Sorry, vertippt. Ich meinte in XSD geht es um Typen. In XML geht es dann um
die Ausprägung dieser Typen.
[...]
>> Reguläre Ausdrücke (als Syntax) sind meiner Meinung nach deutlich
>> schwieriger zu verstehen, was auch daran liegt, dass man diese in der
>> Entwicklung deutlich weniger oft benötigt. Zumindest ist das meine
>> Erfahrung
>> aus der Praxis.
>
> Natuerlich gibt es Leute, die die Ergebnisse aus 50 Jahren
> theoretischer Informatik fuer ueberfluessig und laestig halten.
Wer hat das behauptet?
> Meistens sieht man es deren Software"loesungen" auch an.
Wovon redest Du?
> Der OP sieht auch DTDs als das intuitivere an.
Und was soll das beweisen? DTDs sind natürlich leichter zu verstehen, weil
sie weniger abbilden.
[...]
> In den genannten Programmiersprachen formuliert man einen inhaerent
> imperativen Algorithmus in einer dafuer geeigneten Programmiersprache
> (fuer Faelle wo andere Programmierparadigmen besser geeignet sind gibt
> es aber ja auch entsprechend andere Programmiersprachen). XSD ist aber
> eben
> nicht der geeignetste Formalismus, um Baumstrukturen zu beschreiben.
So absolut ist das wenig nachvollziehbar. Du solltest es in eine vernünftige
Relation setzen. Es geht bei XSD nun einmal nicht mehr nur um simple
Baumstrukturen.
[Web-Services]
>> Es sollte wohl naheliegend gewesen sein, dass ich die Programmierung
>> meinte.
>
> Programmierung ohne Verstaendnis halte ich fuer riskant und im
> Ergebnis oft qualitativ minderwertig.
Wie kommst Du darauf, dass es ein entweder oder ist? Ich hatte doch
geschrieben, dass das Verständnis vorliegen muss.
Gruß,
Daniel
Daniel Urban
> Daniel Urban
>> XSD beschreibt etwas einfaches und bekanntes: Objekte/Typen.
>
> Was aber nicht unbedingt zu den Konzepten XML passt.
Mag schon sein, dass es dem ursprünglichen Konzept zuwider läuft. Aber
entspricht der gängigen Praxis.
> Natuerlich kann man alles als Typen sehen, es ist aber oft eben nicht
> die intuitivste (und damit am wenigsten fehleranfaellige) Art.
Unter Informatikern würde ich vermuten, dass es die deutlich intuitivere
Sichteweise ist, weil sie den üblichen Paradigmen nahe kommt.
[...]
>> Es geht also um Datenstrukturen, die mit geeigneter Syntax beschrieben
>> werden müssen.
>
> Zuerst mal geht es um spezielle Datenstrukturen: Baeume. Und fuer die
> gibt es an sich besser geeignete, spezielle Formalismen.
Das will ich auch nicht grundsätzlich bezweifeln. Aber XML wird nun mal
nicht nur für Baumstrukturen eingesetzt, sondern für beliebige Strukturen.
Man kann - und ich sage das teilweise auch - der Meinung sein, dass man
nicht alles nach XML abbilden sollte. Zum Glück lässt die Mode alles in XML
auszudrücken endlich nach.
>> > Kommerzielle Tools sollten das hoffentlich sein. Da ich fuer die
>> > universitaere Ausbildung und den Heimgebrauch aber nur
>> > nicht-kommerzielle Versionen empfehlen kann, sehe ich die Situation da
>> > deutlich eingeschraenkter.
>>
>> Das ist natürlich eine unschöne Einschränkung. In der Praxis sollte diese
>> aber nicht gelten.
>
> Fuer die meisten kleineren Projekte -und viele, die auf XML arbeiten
> sind solche- gilt sie.
Kann ich nicht nachvollziehen. Meine Wahrnehmung ist da eine ganz andere.
Gruß,
Daniel
Daniel Urban
>> Es geht auch in der Regel nicht um reguläre Ausdrücke, sondern um Typen
>> und
>> Objekte. Du hast zum Beispiel auch JAX-B genannt, wo letztendlich nur von
>> einer "Programmiersprache" (XML) in die andere (Java) transformiert wird.
>> Bei Web-Services werden Werte mit bestimmten Typen verschickt.
>
> Das was man in JAXB verwendet ist eine kleine Untermenge dessen was
> XML umfasst.
Funktional ist das natürlich richtig. Aber wenn ich mir die Verwendung von
XML im Umfeld z.B. von Java anschaue, dann habe ich da als Hauptfelder:
Konfigurationsdateien und Kommunikation (Web-Service, Export, Import usw.)
Die Betrachtung als Baum oder als Dokument ist dort weniger ausgeprägt.
Selbst wenn ich mir Reporting (z.B. FOP) anschauen, besteht ein Großteil aus
beliebigen Datenstrukturen bestimmter Typen.
Gruß,
Daniel
Daniel Urban
> Wolfgang May schrieb:
[...]
>> geeignet. Es gibt aber auch Dinge, wo es schmerzhaft wird, und man
>> zuviel prozedurales ins funktionale reintricksen muss, um etwas halt
>> noch irgendwie in XSLT machen zu koennen.
>
> Ist dies der Grund, warum in verbreiteten Architekturen, wo es ums
> Publizieren geht, wie z.B. Wordpress oder Joomla XSLT nicht verwendet
> wird?
Mm... Wenn es um das Publizieren geht, dann ist XSLT und FOP eigentlich eine
freie Lösung, die AFAIK durchaus eingesetzt wurde. Ich durfte durchaus mal
XSLT ändern, welches z.B. vom Framemaker verwendet wurde.
XML scheint mir im Umfeld von Dokumenten und XSLT im Umfeld von
Transformationen von Dokumenten noch am sinnvollsten einzusetzen zu sein.
Gruß,
Daniel
Daniel Urban
[...]
> Was wäre denn heute Dein Mittel der Wahl um in XML ausgezeichnete
> Artikel gezielt zu manipulieren?
Ich arbeite in einem Umfeld, wo das XML nicht ein Dokument, sondern eine
Objekt-Struktur darstellt. D.h. ich generieren mir zum Beispiel mit JAX-B
eine entsprechende Struktur, die ich dann gezielt verändere. Ich abreite
also auf getypten Klassen.
Ich habe Dein konkretes Beispiel leider nicht verstanden. Was manipulierst
Du hier? Für mich sieht das nach einer Web-Anwendung aus. Diese würde ich
mit einer gängigen Programmiersprache bauen, die mir dynamische HTML-Seiten
generieren kann. Aber vielleicht ist das für Deinen Anwendungsfall schon zu
viel.
Gruß,
Daniel
Andreas Borutta
> "Andreas Borutta"
> [...]
>> Was wäre denn heute Dein Mittel der Wahl um in XML ausgezeichnete
>> Artikel gezielt zu manipulieren?
>
> Ich arbeite in einem Umfeld, wo das XML nicht ein Dokument, sondern eine
> Objekt-Struktur darstellt.
OK. Das ist etwas anderes als das, was mir vorschwebt.
Mir geht es um das Publizieren von Artikeln.
Beispiel:
Artikel zum Thema Verkehrsplanung und Fahrradverkehr - mit einem
Umfang, der 8 A4 Seiten entspricht, reichlich Überschriften,
Datentabellen mit Meßwerten, Formeln, diversen Überschriftenebenen,
einem Interview, Listen, Anmerkungen, Literaturverweisen, Bilder mit
Bildunterschriften, ...
Also einmal quer durch die Markupmöglichkeiten von XHTML durch.
Immer mal wieder kommt es vor, dass neue Inhaltstypen dazukommen. Dann
werden neue IDs oder Klassen eingeführt.
(Künftig, falls sich XML als geeignet erweist, vielleicht stattdessen
neue Elemente und eine Erweiterung der XHTML-DTD - aber die
praxisrelevanten Aspekte überblicke ich noch längst nicht,
insbesondere was Barrierearmut angeht.)
> D.h. ich generieren mir zum Beispiel mit JAX-B
> eine entsprechende Struktur, die ich dann gezielt verändere. Ich abreite
> also auf getypten Klassen.
>
> Ich habe Dein konkretes Beispiel leider nicht verstanden. Was manipulierst
> Du hier?
Das ist ganz gewöhnliches handgeschriebenes XHTML.
Jedesmal, wenn neue Artikel dazukommen, werden einige wenige Zeilen in
der <ul id="sitemap"> ergänzt.
Aus dieser "Referenz"-Liste (die nicht ausgeliefert wird), soll die
ausgelieferte Navigation für die jeweiligen Seiten entstehen.
Jetzt klarer?
> Für mich sieht das nach einer Web-Anwendung aus.
Ein Webinterface benötigen wir nicht.
Auch kein ausgewachsenes Redaktionsinterface mit komplettem Workflow
mit Vorschlag, Absegnen, zeitgesteuertem Veröffentlichen, ...
Zuviel für ein kleines, freies online veröffentlichtes
Fahrrad-Magazin.
> Diese würde ich
> mit einer gängigen Programmiersprache bauen, die mir dynamische HTML-Seiten
> generieren kann. Aber vielleicht ist das für Deinen Anwendungsfall schon zu
> viel.
Das kann ich nicht beurteilen.
Das Ganze war ja auch nur ein Beispiel.
Jedenfalls empfinde ich eine XML-Sitemap (steht ja auch im Beispiel)
als perfekt geeignet als Quelle für jedwede Navivariante.
Als Ausbaustufe möchte ich auch die Inhaltsverzeichnisse (TOC) für
jede Seite ebenfalls mit in die XML-Sitemap aufnehmen, weil sie IMHO
dort hervoragend hineinpasst. *
Auch in Büchern gibt es es ja typischerweise ein Gesamtverzeichnis
aller Inhalte.
Andreas
*
Als Quelle:
| <sitemap title="Lorem Ipsum">
| <item dir="thema-1" title="Thema 1">
| <item dir="thema-1.1" title="Thema 1.1"/>
| <item dir="thema-1.2" title="Thema 1.2"/>
| </item>
| <item dir="thema-2" title="Thema 2">
| <item dir="thema-2.1" title="Thema 2.1">
| <item dir="thema-2.1.1" title="Thema 2.1.1"/>
| <item dir="thema-2.1.2" title="Thema 2.1.2">
| <item type="toc" id="thema-2.1.2.1" title="Thema 2.1.2.1"/>
| <item type="toc" id="thema-2.1.2.2" title="Thema 2.1.2.2"/>
| <item type="toc" id="thema-2.1.2.3" title="Thema 2.1.2.3"/>
| </item>
| <item dir="thema-2.1.1" title="Thema 2.1.3"/>
| </item>
| <item dir="thema-2.2" title="Thema 2.2"/>
| </item>
| <item dir="faq" title="FAQ" role="faq"/>
| <item dir="kontakt" title="Kontakt" role="contact"/>
| </sitemap>
Ausgeliefert in manipulierter Form:
| <div id="nav-main">
| <ul>
| <li><a href="/">Startseite</a></li>
| <li><a href="/thema-1/">Thema 1</a></li>
| <li><a href="/thema-2/"><strong>Thema 2</strong></a></li>
| </ul>
| </div>
| <div id="nav-detail">
| <ul>
| <li><a href="/thema-2/thema-2.1/"><strong>Thema 2.1</strong></a>
| <ul>
| <li><a href="/thema-2/thema-2.1/thema-2.1.1">Thema 2.1.1</a></li>
| <li id="current"><strong>Thema 2.1.2</strong></li>
| <li><a href="/thema-2/thema-2.1/thema-2.1.3">Thema 2.1.3</a></li>
| </ul>
| </li>
| <li><a href="/thema-2/thema-2.2/">Thema 2.2</a></li>
| </ul>
| </div>
| <div id="toc">
| <ul>
| <li><a href="#thema-2.1.2.1">Thema 2.1.2.1</a></li>
| <li><a href="#thema-2.1.2.2">Thema 2.1.2.2</a></li>
| <li><a href="#thema-2.1.2.3">Thema 2.1.2.3</a></li>
| </ul>
| </div>
--
http://borumat.de
Daniel Urban
> Mir geht es um das Publizieren von Artikeln.
Nur in XHTML oder auch in anderen Formaten?
> Beispiel:
> Artikel zum Thema Verkehrsplanung und Fahrradverkehr - mit einem
> Umfang, der 8 A4 Seiten entspricht, reichlich Überschriften,
> Datentabellen mit Meßwerten, Formeln, diversen Überschriftenebenen,
> einem Interview, Listen, Anmerkungen, Literaturverweisen, Bilder mit
> Bildunterschriften, ...
> Also einmal quer durch die Markupmöglichkeiten von XHTML durch.
Ich verstehe das so, dass die Artikel bereits in XHTML ankommen. Ich nehme
mal an, dass zum Schreiben der Artikel ein Tool verwendet wird und man diese
Dinge nicht per Hand schreibt.
> Immer mal wieder kommt es vor, dass neue Inhaltstypen dazukommen. Dann
> werden neue IDs oder Klassen eingeführt.
Mmm... irgendwie kann ich diese Anforderung nicht mit Deinem Beispiel
zusammenbringen. Was sind in Deinem Beispiel die IDs und Klassen? Und woher
kommen diese. Sind sie Teil des Artikels und dort automatisch zu entnehmen
oder ist das eine redaktionelle Arbeit?
[...]
> Das ist ganz gewöhnliches handgeschriebenes XHTML.
> Jedesmal, wenn neue Artikel dazukommen, werden einige wenige Zeilen in
> der <ul id="sitemap"> ergänzt.
Ich verstehe das so, dass Du die Artikel bekommst und dazu statisch einen
Index (Inhaltsverzeichnis über alle Dokumente) erzeugen willst.
Das Erstellen dieses Index erfolgt per Hand? Oder soll das automatisiert
werden? Letzteres wäre möglich, wenn entsprechende Anker vorhanden sind.
Wenn Du es per Hand machst, weil dafür z.B. eine fachliche Bewertung
erfolgen muss, dann brauchst Du vermutlich kein Tool.
Wenn es automatisch gemacht werden soll, so wären ein paar Rahmenbedingungen
zu prüfen. Wie viele Dokumente werden es? Die Frage ist interessant, wenn
man sich überlegt, generell immer den ganzen Index neu zu generieren. Wenn
es viele Dokumente sind, dann wäre ggf. der von Dir angedachte Weg, der
Manipulation sinnvoll.
Deine Formulierung deutet für mich darauf hin, dass der Fall eher selten
eintritt, also nicht jede Minute oder jeden Tag. Auch die Menge an neuen
Dokumenten scheint recht gering zu sein.
> Aus dieser "Referenz"-Liste (die nicht ausgeliefert wird), soll die
> ausgelieferte Navigation für die jeweiligen Seiten entstehen.
Ok. Das hört sich dann nach XSLT in relativ einfacher Form an.
Aber dafür brauchst Du keinen Server, keine Datenbank usw. Da schreibst Du
Dir ein Batch-Skript, welches einen XSLT-Prozessor auf der Datei aufruft.
Die entstandene Seite schiebst Du dann auf Deine Homepage mit den üblichen
Mitteln.
[...]
> Das Ganze war ja auch nur ein Beispiel.
> Jedenfalls empfinde ich eine XML-Sitemap (steht ja auch im Beispiel)
> als perfekt geeignet als Quelle für jedwede Navivariante.
Ich kann mir bessere Quellen vorstellen, aber man muss eben mit dem leben,
was man hat.
Gruß,
Daniel
Wolfgang May
> "Wolfgang May"
> > Daniel Urban
> [...]
> >> XML ist umständlich, aber inhaltlich geht es um Typen.
> >
> > Eigentlich eben nicht. Es geht um Strukturen. Um Baeume.
>
> Sorry, vertippt. Ich meinte in XSD geht es um Typen. In XML geht es dann um
> die Ausprägung dieser Typen.
Nein. Es geht um Baeume. Datenstrukturen (um mal den altmodischen Ausdruck
zu benutzen) mit speziellen Eigenschaften.
Klassen/Typen sind natuerlich ein allgemeinstes Konzept der objektorientierten
Implementierung, aber aus konzeptueller Sicht zur Modellierung und Entwurf
nicht optimal, da man wesentliche Eigenschaften der speziellen Struktur des
Problems und der Loesung bereits aus den Augen verloren hat.
> [...]
> >> Reguläre Ausdrücke (als Syntax) sind meiner Meinung nach deutlich
> >> schwieriger zu verstehen, was auch daran liegt, dass man diese in der
> >> Entwicklung deutlich weniger oft benötigt. Zumindest ist das meine
> >> Erfahrung
> >> aus der Praxis.
> >
> > Natuerlich gibt es Leute, die die Ergebnisse aus 50 Jahren
> > theoretischer Informatik fuer ueberfluessig und laestig halten.
>
> Wer hat das behauptet?
In obigem Fall: ich.
Es ist aber leider oft so. "Wozu theoretische Konzepte, wenn ich in
Java|PHP|Perl alles programmieren kann, was ich will".
> > Meistens sieht man es deren Software"loesungen" auch an.
>
> Wovon redest Du?
Von schlecht runtergehackter schlechter Software.
> > Der OP sieht auch DTDs als das intuitivere an.
>
> Und was soll das beweisen?
Dass nicht jeder Deine Aussage, dass Typen das dem Entwickler naheliegendere seien,
und regulaere Ausdruecke deutlich schwieriger zu verstehen sind, teilt.
> DTDs sind natürlich leichter zu verstehen, weil
> sie weniger abbilden.
Vor allem, weil sie einen geeigneteren Formalismus dafuer verwendet.
> [...]
> > In den genannten Programmiersprachen formuliert man einen inhaerent
> > imperativen Algorithmus in einer dafuer geeigneten Programmiersprache
> > (fuer Faelle wo andere Programmierparadigmen besser geeignet sind gibt
> > es aber ja auch entsprechend andere Programmiersprachen). XSD ist aber
> > eben
> > nicht der geeignetste Formalismus, um Baumstrukturen zu beschreiben.
>
> So absolut ist das wenig nachvollziehbar. Du solltest es in eine vernünftige
> Relation setzen. Es geht bei XSD nun einmal nicht mehr nur um simple
> Baumstrukturen.
Um wenig mehr. Zentral ist dabei immer noch die Baumstruktur. XSD
verklausuliert das allerdings so, dass viele Leute das nicht mal mehr
erkennen. Mit dem Ergebnis, dass sie darauf so programmieren, wie in
Datenstrukturen ueblich, ohne von dem inhaerenten Nutzen der Baumstruktur
zu profitieren.
> [Web-Services]
> >> Es sollte wohl naheliegend gewesen sein, dass ich die Programmierung
> >> meinte.
> >
> > Programmierung ohne Verstaendnis halte ich fuer riskant und im
> > Ergebnis oft qualitativ minderwertig.
>
> Wie kommst Du darauf, dass es ein entweder oder ist? Ich hatte doch
> geschrieben, dass das Verständnis vorliegen muss.
na, dann sind wir uns ja prinzipiell doch einig.
Wolfgang
Wolfgang May
> "Wolfgang May"
> > Daniel Urban
> >> XSD beschreibt etwas einfaches und bekanntes: Objekte/Typen.
> >
> > Was aber nicht unbedingt zu den Konzepten XML passt.
>
> Mag schon sein, dass es dem ursprünglichen Konzept zuwider läuft. Aber
> entspricht der gängigen Praxis.
Ja, in gewissen Kreisen.
Das sind prinzipiell dieselben, die auch in den 90ern in C++ und Java
noch ihren PASCAL-Spaghetticode-Stil programmiert haben. Ging natuerlich
auch. Kein Konzept der Informatik kann sich dagegen wehren, nicht verstanden
und falsch eingesetzt zu werden.
Das Ergebnis ist hoeherer programmieraufwand (und damit teurer), mehr
Fehler (die garnciht passieren koennten, wenn man geeignete Konzepte
verwenden wuerde), und schlechtere Wartbarkeit (und nochmal teurer).
> > Natuerlich kann man alles als Typen sehen, es ist aber oft eben nicht
> > die intuitivste (und damit am wenigsten fehleranfaellige) Art.
>
> Unter Informatikern würde ich vermuten, dass es die deutlich intuitivere
> Sichteweise ist, weil sie den üblichen Paradigmen nahe kommt.
Der OP zumindest fand auch DTDs die intuitivere Sichtweise ...
> [...]
> >> Es geht also um Datenstrukturen, die mit geeigneter Syntax beschrieben
> >> werden müssen.
> >
> > Zuerst mal geht es um spezielle Datenstrukturen: Baeume. Und fuer die
> > gibt es an sich besser geeignete, spezielle Formalismen.
>
> Das will ich auch nicht grundsätzlich bezweifeln. Aber XML wird nun mal
> nicht nur für Baumstrukturen eingesetzt, sondern für beliebige Strukturen.
Jein. Eigentlich nur zur Serialisierung und Datenaustausch solcher
(SOAP, JAXB). Und dann sollte man nicht versuchen, auf dem Zeug auf
XML-Ebene zu arbeiten, sondern automatisch marshallen/unmarshallen.
Dort wo man quasi nur einfache Objekte als Beans (was man in den
1970ern als records aber prinzipell auch schon kannte) hat, reicht XML
notfalls aus, um Objekte als XML-Fragmente zu sehen. Dann hat es aber
mit XML und content model etc. wenig zu tun, sondern ist nur eine
Serialisierung von irgendwas in XML (JAXB zum Beispiel). Dazu wird
eine mickrige Untermenge von XSD benoetigt (und die entsprechenden
Ausdruecke waeren in DTD auch eine extrem einfache und kleine
Untermenge von regulaeren Ausdruecken, und deutlich kuerzer als in
XSD). Schon (FOP-)Dokumente deckt die Untermenge IMHO nicht ab, weil
z.B. sections (oder wie auch immer das in FOP heisst, ich nehme mal
die LaTeX-Terminologie) eine beliebige Folge von paragraphs, tables,
figures, etc haben koennen. JAXB's get/set-Methoden kaemen damit
garnicht klar.
Bei CORBA und ODMG haette man zur Serialisierung solch einfacher
Objektchen halt ODL und OIF genommen. Heute nimmt man json und spart
sich das ganze XML-Gedoens auch wieder.
> Man kann - und ich sage das teilweise auch - der Meinung sein, dass man
> nicht alles nach XML abbilden sollte. Zum Glück lässt die Mode alles in XML
> auszudrücken endlich nach.
Gluecklicherweise.
Wolfgang
Wolfgang May
> "Wolfgang May"
> > Daniel Urban <urba...@cs.tu-berlin.de> wrote:
> [...]
> >> Es geht auch in der Regel nicht um reguläre Ausdrücke, sondern um Typen
> >> und
> >> Objekte. Du hast zum Beispiel auch JAX-B genannt, wo letztendlich nur von
> >> einer "Programmiersprache" (XML) in die andere (Java) transformiert wird.
> >> Bei Web-Services werden Werte mit bestimmten Typen verschickt.
> >
> > Das was man in JAXB verwendet ist eine kleine Untermenge dessen was
> > XML umfasst.
>
> Funktional ist das natürlich richtig. Aber wenn ich mir die Verwendung von
> XML im Umfeld z.B. von Java anschaue, dann habe ich da als Hauptfelder:
> Konfigurationsdateien und Kommunikation (Web-Service, Export, Import usw.)
Selbst da (bzw. gerade bei Konfigurationsdateien) koennte der
Programmierer der entsprechenden Anwendung oft davon profitieren, wenn er wuesstem
dass man mit XPath ganz einfach (und robust, falls sich die Syntax der
Konfig-Datei mal aendert) die benoetigten Informationen rausholen kann,
anstatt ewig mit Java und Iterationen auf einer Objektstruktur herumzunudeln.
> Die Betrachtung als Baum oder als Dokument ist dort weniger ausgeprägt.
> Selbst wenn ich mir Reporting (z.B. FOP) anschauen, besteht ein Großteil aus
> beliebigen Datenstrukturen bestimmter Typen.
Ein Dokument ist an sich eine ganz typische Anwendung einer
Baumstruktur, wo man deren Eigenschaften oft auch ausnutzen
kann und sollte. XPath, XQuery und XSLT bieten dafuer eine built-in
Ausdruckskraft fuer die ueblichen Operationen Durchlaufen, Suchen,
Aufzaehlen etc, die man bei der fehlenden Abstraktion als Struktur von
Instanzen verschiedener Typen explizit ausprogrammieren muss. Gerade
mit Hinblick auf Dokumente wurde ja XSLT als XML->XML- und damit auch
XML->XHTML-Transformationssprache geschaffen. Natuerlich kann man es
objektorientiert ausprogrammieren, aber die Entwickler der
XML-Sprachen allgemein und XSLT im speziellen haben die Erkenntnis,
dass es dabei typische Verwendungspatterns gibt, dahingehend umgesetzt,
geeignete deklarative Sprachen zu designen (und effiziente und
optimierte Implementierungen anzubieten).
Auf FOP (oder sonstigen Dokumenten) dann doch wieder mit Java
zu operieren ist ein Rueckschritt im Abstraktionsniveau. Und fuehrt
damit zu aufwendigerem Programmieren, mehr Fehlern und schlechterer
Wartbarkeit.
Wolfgang
Wolfgang May
> Wolfgang May schrieb:
>
> Erstmal herzlichen Dank für Deine sehr ausführliche Antwort.
>
> >> Welche Aufgaben interessieren mich zunächst vorrangig?
> >>
> >> XHTML-Dokumente (später auch XML) sollen gezielt verändert, gekürzt,
> >> anreichert werden.
> >
> > XSLT, XQuery, oder - mit Einschraenkungen XML Query mit Updates (das
> > ist etwas anderes als XML:DB's XUpdate, was es auch gibt, aber eher
> > mit XSLT verwandt ist, in 1999/2000 entwickelt wurde, dann eingestellt
> > wurde, und und eher selten ist; z.B. der eXist Server verwendete es).
> >
> > Eine Frage ist dabei: willst Du das Ausgangsdokument behalten und
> > ausserdem ein neues Dokument haben (XQuery, XSLT) ,
>
> Genau das.
> Wobei das "neue" Dokument nur auf Anfrage erzeugt wird. (Es wird
> allenfalls, wenn nötig, aus Performancegründen, in einem Cache
> abgelegt.) Der Charakter des neuen Dokumentes soll flüchtig sein.
> Anders ausgedrückt:
> Alles was von Dauer ist, Struktur und Semantik des Kerninhaltes
> (Artikels), wird im Dokument abgelegt.
Dann ist XSLT und XQuery bestens geeignet.
> Der ganze andere Schlunz wie Navi, Suchfunktion,
Ja, das gehoert nicht direkt zum Dokument.
> etc. aber auch die
> Kopfdaten, die zu den gerade aktuellen Clients passen - all das soll
> völlig davon abgetrennt sein.
Bei den Header-Daten koennte man am Ende noch darueber nachdenken,
sie mit einzubeziehen. Das geht an sich ganz gut.
> Eine andere wesentliche architektonische Frage, ob die Inhalte in
> einer Datenbank oder "nur" in der Verzeichnisstruktur liegen, die
> möchte ich in diesem Thread bewußt ausklammern.
Das ist gut und richtig.
Mit den o.g. Sprachen ist das auch egal. Die gibts als separate
Programme, hauptspeicherbasiert (saxon z.B.), oder auch integriert
in Dokumentenmanagementsysteme (eXist usw) und auch in Datenbanken
(Oracle usw). Das kannst Du also dann auch jederzeit noch aendern.
> > Das kommt darauf an, in welcher Weise die Aufgabe komplex ist. XSLT
> > und XML Schema (oft auch als XSD bezeichnet; falls die synonyme
> > Benutzung dieser beiden Begriffe/Akronyme Dich irgendwie verwirren
> > sollte) haben gemeinsam, dass beide etwas in XML ausdruecken. Soweit,
> > so geschwaetzig. Der Unterschied -IMHO- ist, dass XSD dabei aber auch
> > konzeptuell nicht die naheliegendste Loesung ist (und damit doppelt
> > laestig). Bei XSLT ist es anders: das was es beschreibt, ist sehr gut
> > so beschreibbar; zwar etwas geschwaetzig, aber konzeptuell sehr
> > treffend. Andererseits ist XSLT von Art des Denkens und des Ablaufs
> > gewoehnungsbeduerftig - wenn man es aber mal raus hat, ist es fuer
> > viele Probleme optimalst und knackig kurz und uebersichtlich (weil es
> > etwas "anders" ist). Grob: wenn man gut die Baumstruktur nutzen kann,
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Das sollte der Fall sein, da es um wohlgeformtes und valides XML geht.
Davon geht man wenn man XML sagt, immer aus.
Sonst kann man ja wirklich nur mit Stringpopeln und eckigen Klammern
was machen, oder muss zumindest mit einen fehlerkorrigierenden Parser
wie in HTML-Browsern rangehen und hoffen.
> > und "regelbasiert" ein Element lokal betrachten und behandeln
> > (umformen und das Ergebnis in den Output haengen) kann,
>
> Hier ist mir noch klar, was Du damit genau meinst.
Ich meinte damit, das fuer XSLT charakteristische Tree-Jumping: man
befindet sich virtuell immer "auf einem Knoten", den man gerade (mit
einem dafuer vorgesehenen Template) bearbeitet. Von dort springt man
ggf weiter auf andere etc. Fuer jeden Elementtypen hat man ein
bestimmtes Template (=eine Regel, ggf auch mehrere wenn man in
unterschiedlichen Situationen verschiedene hat, siehe
xsl:mode-Attribut), die angibt, wie es verarbeitet wird. Dabei hat man
keine expliziten Aufrufe "forall subelements x: procedure_p(x)",
sondern nur "apply-templates(my-subelements)". Je nachdem, von welchem
Elementtyp das einzelne Element dann ist, wird waehlt XSLT die dafuer
zustaendige Regel aus. Als Output wird dabei alles aufgesammelt was
dabei produziert wird. Es geht inzwischen auch, den Template-Aufrufen
(=Spruengen) Knoten als Parameter mitzugeben, aber da wird es schon
un-XSL-ig und kommt an die Grenze, wo eigentlich XQuery und sein
funktionaler Programmierstil sinnvoller waeren.
> > ist XSLT sehr
> > geeignet. Es gibt aber auch Dinge, wo es schmerzhaft wird, und man
> > zuviel prozedurales ins funktionale reintricksen muss, um etwas halt
> > noch irgendwie in XSLT machen zu koennen.
>
> Ist dies der Grund, warum in verbreiteten Architekturen, wo es ums
> Publizieren geht, wie z.B. Wordpress oder Joomla XSLT nicht verwendet
> wird?
Keine Ahnung.
Wundert mich, dass sie es nicht tun (ich wuerde es wohl vermissen, aber
der normale benutzer wohl nicht), aber selber kenne ich mich mit
denen nicht aus.
> Wenn ich alles richtig verstanden habe, empfiehlst Du deutlich die
> Verwendung von XSLT/XQuery und rätst von den allgemeinen
> Programmiersprachen - für die skizzierten Aufgaben - ab.
Ja, auch und gerade nachdem die Beschreibung Deines Anwendungsfalls
naeher gelesen habe. Im wesentlichen willst Du ja wirklich nur
Dokumente herumschaukeln und evtl ein bisschen umformatieren und
aufbereiten, Listen/Indexe darueber anlegen.
Wolfgang
Wolfgang May
> Immer mal wieder kommt es vor, dass neue Inhaltstypen dazukommen. Dann
> werden neue IDs oder Klassen eingeführt.
Ich wuerde das jetzt interpretieren, dass Du nicht Klassen aus
informatischer Sicht, sondern aus inhaltlicher Sicht ("Tabellen zu Bla",
"Tabellen zu Blubb") meinst, und IDs dazu von aussen eine bestimmte
Tabelle in einem Dokument anhand ihrer ID referenzieren zu koennen?
> (Künftig, falls sich XML als geeignet erweist, vielleicht stattdessen
> neue Elemente und eine Erweiterung der XHTML-DTD -
Erweiterung der XHTML-DTD wuerde bedeuten dass Du neue Begriffe
zu XHTML hinzufuegen wolltest (aehm: Problem: kein Browser versteht sie)?
Oder willst Du nur weitere, eigene Attribute in ein XHTML-Dokument
einfuegen, die keine Semantik fuer den Browser haben, sondern nur
fuer Deine Dokumentverwaltung? Letzeres geht ohne Probleme,
z.B. <xhtml:table my:comment="tabelle zu bla">... </>
Dazu sind de unterschiedlichen namespaces ja da.
> aber die
> praxisrelevanten Aspekte überblicke ich noch längst nicht,
> insbesondere was Barrierearmut angeht.)
Letzteres ist eine ganz andere (ggf sehr zeitraubende, weil jeder Browser auch
XHTML anders darstellt) Baustelle ...
> Das ist ganz gewöhnliches handgeschriebenes XHTML.
> Jedesmal, wenn neue Artikel dazukommen, werden einige wenige Zeilen in
> der <ul id="sitemap"> ergänzt.
>
> Aus dieser "Referenz"-Liste (die nicht ausgeliefert wird), soll die
> ausgelieferte Navigation für die jeweiligen Seiten entstehen.
>
> Jetzt klarer?
Sieht perfekt nach XSLT, evtl in Kombination mit Makefiles/ant aus.
Wolfgang
Wolfgang May
XSLT und XQuery sind auf einem hoeheren Abstraktionsniveau als dom,
dom4j, jdom usw (von denen benutze ich normalerweise jdom wenn ich
unbedingt ueberhaupt in Java abgleiten muss um etwas umzusetzen). Dort
wo XSLT bzw XQuery geeignet sind wird man dasselbe deklarativ in
ca. 1/10 des Codes (und der dafuer benoetigten Zeit) ausdruecken
koennen, wie man fuer ein Ausprogrammieren in Java+jdom benoetigt. Die
Performance kommt massiv darauf an, ob man ein (einfaches)
Hauptspeicher-Tool benutzt, oder eine DB oder ein Hauptspeicher-Tool
das zumindest mal Indexe anlegt.
Der Vergleich ist fast schon so wie die Frage, ob man fuer eine
relationale Datenbank besser SQL benutzt, oder mit C auf den
Speicherstrukturen rumroedelt (Im Prinzip koennte man natuerlich auch
Tupel und Relationen als Klassen auffassen und die relationale Algebra
neu erfinden und (wahrscheinlich ohne Optimierung)
ausprogrammieren). Oder in Assembler.
Immer noch haengen DB nach dem Netzwerkmodell in der Performance SQL
im optimalen Fall ab. Weil halt die Anfrage (jede Anfrage muss man
allerdings erst so ausprogrammieren) quasi harcodiert wird, anstatt
den SQL-Interpreter und seine Heuristiken anzuwenden. Nur ist halt der
Programmieraufwand fuer jede Anfrage erheblich, und die Performance
auch nur besser, wenn der Programmierer die optimale Strategie waehlt.
Wolfgang
Daniel Urban
> Daniel Urban <urba...@cs.tu-berlin.de> wrote:
>> Die Betrachtung als Baum oder als Dokument ist dort weniger ausgeprägt.
>> Selbst wenn ich mir Reporting (z.B. FOP) anschauen, besteht ein Großteil
>> aus
>> beliebigen Datenstrukturen bestimmter Typen.
>
> Ein Dokument ist an sich eine ganz typische Anwendung einer
> Baumstruktur, wo man deren Eigenschaften oft auch ausnutzen
> kann und sollte.
Beim Reporting und mehr noch beim Publizieren ist das auch durchaus
verbreitet.
> XPath, XQuery und XSLT bieten dafuer eine built-in
> Ausdruckskraft fuer die ueblichen Operationen Durchlaufen, Suchen,
> Aufzaehlen etc, die man bei der fehlenden Abstraktion als Struktur von
> Instanzen verschiedener Typen explizit ausprogrammieren muss.
Naja, der üblich Ablauf ist wohl, dass man die Datenstruktur (z.B. Objekte
in Java) serialisiert nach XML und dies als Datenquelle heranzieht. Die
eigentlich Transformation in das Zielformat (z.B. Word) erfolgt dann wohl
wieder in einer höheren Sprache. So sieht zum Beispiel ein Szenario des
Marktführers Crystal Reports aus.
Andere Tools wie zum Beispiel BIRT haben als Eingabe die Daten als XML und
die Templates als XML, ähnlich wie FOP. Aber natürlich sieht der ganze
Prozess dann auch in der Regel so aus, dass die Datenstrukturen nach XML
(z.B. JAX-B) serialisiert werden und von BIRT transformiert werden. Ist das
Zielformat XML, so ist das möglich. Wenn aber ein binäres Zielformat erzeugt
wird, geht das AFAIR dann so einfach nicht mehr.
> Gerade
> mit Hinblick auf Dokumente wurde ja XSLT als XML->XML- und damit auch
> XML->XHTML-Transformationssprache geschaffen.
Da macht es auch noch am meisten Sinn.
> Natuerlich kann man es
> objektorientiert ausprogrammieren, aber die Entwickler der
> XML-Sprachen allgemein und XSLT im speziellen haben die Erkenntnis,
> dass es dabei typische Verwendungspatterns gibt, dahingehend umgesetzt,
> geeignete deklarative Sprachen zu designen (und effiziente und
> optimierte Implementierungen anzubieten).
Schon richtig, aber Du hast selber in dem Thread erwähnt, dass es natürlich
seine Grenzen hat. AFAIR kann man in XSLT auch Methoden aus der ausführenden
Umgebung aufrufen. Das ist ein nettes Feature, aber auch ein Anzeichen, dass
man beginnt, den geeigneten Rahmen zu verlassen.
> Auf FOP (oder sonstigen Dokumenten) dann doch wieder mit Java
> zu operieren ist ein Rueckschritt im Abstraktionsniveau.
Aber teilweise nicht umgänglich, z.B. wenn binäre Formate wie z.B. PDF, Word
usw. erzeugt werden müssen.
> Und fuehrt
> damit zu aufwendigerem Programmieren, mehr Fehlern und schlechterer
> Wartbarkeit.
Ich kann mir nicht vorstellen, wie man aus XSLT binäre Fomate erzeugen will.
Das wäre in meiner Vorstellung auch unwartbar und sehr fehleranfällig. Aber
vielleicht hat sich da über die Jahre auch etwas getan.
Gruß,
Daniel
Andreas Borutta
> Andreas Borutta <bor...@gmx.de> wrote:
>
>> Immer mal wieder kommt es vor, dass neue Inhaltstypen dazukommen. Dann
>> werden neue IDs oder Klassen eingeführt.
>
> Ich wuerde das jetzt interpretieren, dass Du nicht Klassen aus
> informatischer Sicht, sondern aus inhaltlicher Sicht ("Tabellen zu Bla",
> "Tabellen zu Blubb") meinst, und IDs dazu von aussen eine bestimmte
> Tabelle in einem Dokument anhand ihrer ID referenzieren zu koennen?
Richtig, das meinte ich.
>> (Künftig, falls sich XML als geeignet erweist, vielleicht stattdessen
>> neue Elemente und eine Erweiterung der XHTML-DTD -
>
> Erweiterung der XHTML-DTD wuerde bedeuten dass Du neue Begriffe
> zu XHTML hinzufuegen wolltest (aehm: Problem: kein Browser versteht sie)?
Was meinst Du hier mit "verstehen" bitte?
Wenn die DTD wirksam ergänzt wurde, "weiß" der Browser - in Verbindung
mit dem CSS - wie er die Elemente darzustellen hat.
> Oder willst Du nur weitere, eigene Attribute in ein XHTML-Dokument
> einfuegen, die keine Semantik fuer den Browser haben, sondern nur
> fuer Deine Dokumentverwaltung?
Nein, es geht mir vorrangig um Elemente.
<interview></interview>
statt
<div id="interview"></div>
um mal ein sehr einfaches Beispiel zu nennen.
Aber es ist natürlich richtig: eine Semantik haben die Elemente für
den Browser nicht.
Aber die hat
<div id="interview"></div>
auch nicht.
> Letzeres geht ohne Probleme,
> z.B. <xhtml:table my:comment="tabelle zu bla">... </>
> Dazu sind de unterschiedlichen namespaces ja da.
Namespaces muss ich mir noch genauer anschauen.
Vermutlich mindert ihre Verwendung jedoch die Lesbarkeit von Code und
scheidet daher für mich aus.
>> aber die
>> praxisrelevanten Aspekte überblicke ich noch längst nicht,
>> insbesondere was Barrierearmut angeht.)
>
> Letzteres ist eine ganz andere (ggf sehr zeitraubende, weil jeder Browser auch
> XHTML anders darstellt) Baustelle ...
Ich dachte dabei gar nicht an die Auswirkung von Gestaltanweisungen
auf die Zugänglichkeit.
Nein mir geht es zunächst mal nur um die Zugänglichkeit von XHTML ganz
ohne CSS.
Zum Beispiel verbietet es sich im Hinblick auf Barrierearmut eigene
Elemente für Überschriften zu verwenden.
Screenreader interpretieren solche Elemente nicht als Überschrift und
versagen somit ihren Nutzern Hilfstechniken, wie z.B. das Hangeln
durch die Überschriftenstruktur.
>> Das ist ganz gewöhnliches handgeschriebenes XHTML.
>> Jedesmal, wenn neue Artikel dazukommen, werden einige wenige Zeilen in
>> der <ul id="sitemap"> ergänzt.
>>
>> Aus dieser "Referenz"-Liste (die nicht ausgeliefert wird), soll die
>> ausgelieferte Navigation für die jeweiligen Seiten entstehen.
>>
>> Jetzt klarer?
>
> Sieht perfekt nach XSLT, evtl in Kombination mit Makefiles/ant aus.
An python finde ich das Merkmal "Leeraum ist Teil der Syntax" sehr
attraktiv.
Denkst du, dass man mit Python ebenfalls auf "gute Weise" auf den Baum
zugreifen kann um bestimmte Manipulationen - siehe mein bereits
gepostetes Beispiel zur Sitemap - vorzunehmen?
Oder ist ruby on rails der "Königsweg"?
Hintergrund meiner Frage:
Ohne Koketterie weiß ich von mir, dass meine Begabung nicht im
erlernen des Programmierens liegt. Das fällt mir schwer.
Daher wäre es schön, wenn die Wahl auf eine Sprache fällt, die gut
dokumentiert ist, wo es gute anschauliche beispiele gibt und die recht
universell verwendbar wäre.
Ohne dass sie dabei konzeptionell ungeeignet sein darf für "den
Zugriff auf den Baum".
Andreas
--
http://borumat.de
Andreas Borutta
>> Sollte man - ganz allgemein gesprochen - eigentlich Konstruktionen wie
>>
>>| <foo>Lorem
>>| <bar>Ipsum</bar>
>>| <bar>Doloret</bar>
>>| </foo>
>>
>> lieber vermeiden und so einem "losen Zeicheninhalt" lieber ein Element
>> "verpassen"?
>>
>>| <foo>
>>| <zot>Lorem</zot>
>>| <bar>Ipsum</bar>
>>| <bar>Doloret</bar>
>>| </foo>
>>
>> Mir erschien die erste Variante eleganter, weil sie weniger Code
>> benötigt.
>
> Glaubensfrage. Mixed contents ist pfui ;)
Aus Sicht desjenigen, der Inhalte schreibt und auszeichnet, nicht.
Nicht ohne Grund gibt es deshalb gemischen Inhalt in HTML.
Oder siehst Du aus dieser Sicht einen konzeptionellen Nachteil.
Aus Sicht des Programmierers mag gemischter Inhalt schlecht sein.
Aber dann fehlt vielleicht eine Programmiersprache, die damit
vernünftig umgehen kann.
> Nachteil: wenn Du auf Lorem zugreifen willst, vergleichen willst
> etc kannst Du nur [foo/text() ='bla'] machen (und musst daran denken)
> weil [foo='bla'] naemlich den Stringwert LoremIpsumDoloret ansetzen
> wuerde, waehrend mit der zweiten Variante [foo/zot ='bla'] explizit
> und klarer ist.
>
>> Auch im Hinblick auf praktische Gesichtspunkte beim Publizieren im Web
>> und dem Gestalten per CSS kommt man mit der ersten Variante recht
>> weit.
>
> Mit CSS kenne ich mich nicht wirklich aus.
> Ich wuerde es nicht machen, weil man dann ein Stueck Text hat, was sich
> nicht "positiv" und als ganzes von dem Restinhalt des Elements
> selektieren laesst.
>
> Ach ja, noch haesslicher wird es, wenn Du aus irgendeinem Grund mal
>
>>| <foo><b>L</b>orem
>>| <bar>Ipsum</bar>
>>| <bar>Doloret</bar>
>>| </foo>
>
> oder sowas machen willst. Obige Selektion durch text() passt dann
> naemlich nicht mehr, und Du wirst versuchen muessen, einen
> Ausdruck fuer "gib mit den Inhalt des foo-Elements vor dem bar-Element"
> zu finden.
Oder "Gib mir den Inhalt von foo, aber nicht den Inhalt aller
Kindelemente von foo. Ausnahme: wenn das Kindelement b ist."
Oder "Gib mir den Inhalt von foo, aber nicht den Inhalt seines 2. bis
letzten Kindelementes."
Oder ...
Andreas
--
http://borumat.de
Wolfgang May
> Wolfgang May schrieb:
> >>| <foo>Lorem
> >>| <bar>Ipsum</bar>
> >>| <bar>Doloret</bar>
> >>| </foo>
> >>
> >> lieber vermeiden und so einem "losen Zeicheninhalt" lieber ein Element
> >> "verpassen"?
> >>
> >>| <foo>
> >>| <zot>Lorem</zot>
> >>| <bar>Ipsum</bar>
> >>| <bar>Doloret</bar>
> >>| </foo>
> >>
> >> Mir erschien die erste Variante eleganter, weil sie weniger Code
> >> benötigt.
> >
> > Glaubensfrage. Mixed contents ist pfui ;)
>
> Aus Sicht desjenigen, der Inhalte schreibt und auszeichnet, nicht.
> Nicht ohne Grund gibt es deshalb gemischen Inhalt in HTML.
Ja. Man muss in HTML zwei Anteile unterscheiden: Strukturierung, und
optisches Markup. Mixed contents ist fuer letzteres gedacht,
z.B. in "<p>Wir haben <em>hier</em> eine <b>D</b>ocument <b>T</b>ype
<b>D</b>escription (<em>DTD</em>) ... </p>".
Aus struktureller Sicht wird nur das gesamte <p>-Element
betrachtet, und alles darin als ganzer Block aufgefasst.
> Oder siehst Du aus dieser Sicht einen konzeptionellen Nachteil.
Ja. So wie ich es oben sehe beabsichtigst Du eher, das umgebende
<foo>-Element auch strukturell in einen ersten Teil "Lorem" und
zwei weitere "Ipsum" und "Doloret" aufzuteilen. Dann waere es
sinnvoll, "Lorem" auch strukturell positiv abzuheben und nciht
nur durch negativ "nicht in einem <bar>-Element".
Es ist etwas aehlich zu der Frage ob man Textstrukturen als
Kap.2 BLA
textextext
2.1 foo ...
2.2 bar ...
fuer gut haelt, oder nicht: ein Verweis auf textextext waere
schwer zu formulieren "In Kap.2" ist zu grob, 2.0 gibts nicht,
also muesste man "am Anfang von Kap.2" oder "Kap.2 vor Kap 2.1"
schreiben. Wegen dem sagen viele Autoren, dass dann
textextext bereits 2.1 "Einfuehrung" ueberschrieben sein muesste.
> Aus Sicht des Programmierers mag gemischter Inhalt schlecht sein.
Nicht immer, siehe oben.
> Aber dann fehlt vielleicht eine Programmiersprache, die damit
> vernünftig umgehen kann.
Vernuenftig bei mixed content heisst "nicht selektiv auf etwas
zugreifen wollen, sondern nur iterativ alles mixed-Zeug durcharbeiten
(und ggf fett/schraeg wie auch immer drucken) und ausgeben".
Da geht mit XSLT/XQuery und allem auch sehr gut.
Nur wird es ggf schwierig auf das nicht-ausgezeichnete Stueck
gezielt zuzugreifen.
Wenn der Schreiber es als strukturellen Block gelesen haben will,
sollte er es auch so auszeichnen.
> > Nachteil: wenn Du auf Lorem zugreifen willst, vergleichen willst
> > etc kannst Du nur [foo/text() ='bla'] machen (und musst daran denken)
> > weil [foo='bla'] naemlich den Stringwert LoremIpsumDoloret ansetzen
> > wuerde, waehrend mit der zweiten Variante [foo/zot ='bla'] explizit
> > und klarer ist.
> >
> >> Auch im Hinblick auf praktische Gesichtspunkte beim Publizieren im Web
> >> und dem Gestalten per CSS kommt man mit der ersten Variante recht
> >> weit.
> >
> > Mit CSS kenne ich mich nicht wirklich aus.
> > Ich wuerde es nicht machen, weil man dann ein Stueck Text hat, was sich
> > nicht "positiv" und als ganzes von dem Restinhalt des Elements
> > selektieren laesst.
> >
> > Ach ja, noch haesslicher wird es, wenn Du aus irgendeinem Grund mal
> >
> >>| <foo><b>L</b>orem
> >>| <bar>Ipsum</bar>
> >>| <bar>Doloret</bar>
> >>| </foo>
> >
> > oder sowas machen willst. Obige Selektion durch text() passt dann
> > naemlich nicht mehr, und Du wirst versuchen muessen, einen
> > Ausdruck fuer "gib mit den Inhalt des foo-Elements vor dem bar-Element"
> > zu finden.
>
> Oder "Gib mir den Inhalt von foo, aber nicht den Inhalt aller
> Kindelemente von foo. Ausnahme: wenn das Kindelement b ist."
Ja, dazu muesste man aber ggf ausser <b> alles aufzaehlen, was im Textteil
(HTML) vorkommen kann.
> Oder "Gib mir den Inhalt von foo, aber nicht den Inhalt seines 2. bis
> letzten Kindelementes."
Auch das ist wieder wenig generisch, schon bei
<b>L</b>o<b>R</b>em <bar>Ipso</bar> ...
waere das ja falsch.
Diese Ausdruecke zeigen, dass es geht, aber eben nicht mit
deklarativen strukturellen (und damit robusten) Mitteln //foo/zot,
sondern nur mit Klein-Klein-Bastelei, die ggf irgendwann nachgefrickelt
werden muss, wenn an vergessen hat, dass da auch noch irgendein anderer
Tag drin sein kann.
Wolfgang
Wolfgang May
> Wolfgang May schrieb:
>
> > Andreas Borutta <bor...@gmx.de> wrote:
> >
> >> Immer mal wieder kommt es vor, dass neue Inhaltstypen dazukommen. Dann
> >> werden neue IDs oder Klassen eingeführt.
> >
> > Ich wuerde das jetzt interpretieren, dass Du nicht Klassen aus
> > informatischer Sicht, sondern aus inhaltlicher Sicht ("Tabellen zu Bla",
> > "Tabellen zu Blubb") meinst, und IDs dazu von aussen eine bestimmte
> > Tabelle in einem Dokument anhand ihrer ID referenzieren zu koennen?
>
> Richtig, das meinte ich.
>
> >> (Künftig, falls sich XML als geeignet erweist, vielleicht stattdessen
> >> neue Elemente und eine Erweiterung der XHTML-DTD -
> >
> > Erweiterung der XHTML-DTD wuerde bedeuten dass Du neue Begriffe
> > zu XHTML hinzufuegen wolltest (aehm: Problem: kein Browser versteht sie)?
>
> Was meinst Du hier mit "verstehen" bitte?
Dass es fuer den Browser (und die Darstellung) keine Semantik hat.
> Wenn die DTD wirksam ergänzt wurde, "weiß" der Browser - in Verbindung
> mit dem CSS - wie er die Elemente darzustellen hat.
Da musst Du noch klaeren, was genau Du alles haben willst. Einer der Vorteile
von XML ist, dass man verschiedene Teilsprachen ja mischen kann.
* HTML (das existierende, das allen Browsern bekannt ist)
* Annotationen, die Du im CSS auch beruecksichtigst, und die auch Einfluss
auf die Darstellung des Dokuments selber haben
(vielleicht <keyword>...</keyword>, was dann rot gedruckt wird, und aber auch
in einen Index aufgenommen wird)
* Annotationen, die nur der Dokumentverwaltung und Verknuepfung dienen, aber
in der direkten Darstellung nicht auftreten, vielleicht
<annotation>das habe ich von XY, irgendwie ist es zweifelhaft</annotation>
was man dann auch mit HTML-Struktur mischen kann
<table themengebiet="bla"/>...</table>
> > Oder willst Du nur weitere, eigene Attribute in ein XHTML-Dokument
> > einfuegen, die keine Semantik fuer den Browser haben, sondern nur
> > fuer Deine Dokumentverwaltung?
>
> Nein, es geht mir vorrangig um Elemente.
> <interview></interview>
> statt
> <div id="interview"></div>
> um mal ein sehr einfaches Beispiel zu nennen.
Ah, OK, das waere der 2. Fall von oben.
> Aber es ist natürlich richtig: eine Semantik haben die Elemente für
> den Browser nicht.
> Aber die hat
> <div id="interview"></div>
> auch nicht.
Mit CSS kannst Du ihnen die aber ja in gewisser Weise zuordnen. Bzw.
nicht direkt fuer den Browser, sondern erstmal fuer die CSS-Ebene
(Darstellungsebene), die ihnen eine Semantik gibt, die der Browser
versteht. Ohne CSS wuerde der Browser sie einfach ignorieren. Kommt
halt drauf an, was Du machen willst.
> > Letzeres geht ohne Probleme,
> > z.B. <xhtml:table my:comment="tabelle zu bla">... </>
> > Dazu sind de unterschiedlichen namespaces ja da.
>
> Namespaces muss ich mir noch genauer anschauen.
> Vermutlich mindert ihre Verwendung jedoch die Lesbarkeit von Code
wenig. Du kannst XHTML als default-Namespace nehmen (die Elemente
heissen dann unveraendert <b> usw.), und "eigene" Namespaces
nur kurz im Header deklarieren xmlns:my="http://bla/meineannotationen"
(die URL muss nicht sinnvoll sein, in HTML ist sie nur ein String)
und dann mit <my:annotation>...</my:annotation> arbeiten.
Der Vorteil ist, dass jeder, der mit der Software mal arbeiten muss,
oder Dokumente dazu erstellt, auch gleich erkennt welche Tags HTML
sind, und welche einen anderen, eigenen Aufgabenbereich haben.
Wichtig koennte das auch werden, wenn Du mal mit jemandem anderen
Dokumente austauschen willst. Und es ist auch fuer Software
einfacher, die Aufgabenbereiche auseinanderzuhalten (siehe unten (*)).
> und scheidet daher für mich aus.
> >> aber die
> >> praxisrelevanten Aspekte überblicke ich noch längst nicht,
> >> insbesondere was Barrierearmut angeht.)
> >
> > Letzteres ist eine ganz andere (ggf sehr zeitraubende, weil jeder Browser auch
> > XHTML anders darstellt) Baustelle ...
>
> Ich dachte dabei gar nicht an die Auswirkung von Gestaltanweisungen
> auf die Zugänglichkeit.
> Nein mir geht es zunächst mal nur um die Zugänglichkeit von XHTML ganz
> ohne CSS.
IMHO ein sehr sinnvoller Aspekt.
> Zum Beispiel verbietet es sich im Hinblick auf Barrierearmut eigene
> Elemente für Überschriften zu verwenden.
Das spraeche fuer die Wahl, alle Annotationen in Attribute zu verlagern.
<table themengebiet="bla"/>...</table>
Allerdings: muss das Original-Dokument (das sowohl Inhalt als auch
Metainformationen enthaelt) barrierearm sein (aus meiner Sicht nicht)?
Du willst doch sowieso mit XSLT oder sonstwie die auszuliefernden
Dokumente (und Uebersichtsseiten, Sammlungen, Verlinkungen etc)
erzeugen. Dort muessen die Annotationen ja garnicht drin sein. Das
kann reines XHTML sein.
> Screenreader interpretieren solche Elemente nicht als Überschrift und
> versagen somit ihren Nutzern Hilfstechniken, wie z.B. das Hangeln
> durch die Überschriftenstruktur.
Deswegen sollte man an sich nicht die XHTML-DTD "erweitern", sondern
seine eigenen Angelegenheiten in separaten Namespaces getrennt halten
(Bezug zu oben (*)). Und dann XHTML generieren, wobei man die
Annotationen verwendet um zu steuern was man generiert.
> >> Das ist ganz gewöhnliches handgeschriebenes XHTML.
> >> Jedesmal, wenn neue Artikel dazukommen, werden einige wenige Zeilen in
> >> der <ul id="sitemap"> ergänzt.
> >>
> >> Aus dieser "Referenz"-Liste (die nicht ausgeliefert wird), soll die
> >> ausgelieferte Navigation für die jeweiligen Seiten entstehen.
> >>
> >> Jetzt klarer?
> >
> > Sieht perfekt nach XSLT, evtl in Kombination mit Makefiles/ant aus.
>
> An python finde ich das Merkmal "Leeraum ist Teil der Syntax" sehr
> attraktiv.
>
> Denkst du, dass man mit Python ebenfalls auf "gute Weise" auf den Baum
> zugreifen kann um bestimmte Manipulationen - siehe mein bereits
> gepostetes Beispiel zur Sitemap - vorzunehmen?
> Oder ist ruby on rails der "Königsweg"?
Damit kenne ich ich wenig aus. Mit python habe ich nur ganz kurz mal
was gebastelt. Von Ruby on Rails schwaermen einige Leute, und die
Argumente erschienen mir plausibel. Man sollte was nehmen, was man
kann, was hoffentlich auch Leute, die an dem Projekt mitarbeiten,
koennen (also nix exotisches). Und nix ungeeignetes.
> Hintergrund meiner Frage:
> Ohne Koketterie weiß ich von mir, dass meine Begabung nicht im
> erlernen des Programmierens liegt. Das fällt mir schwer.
> Daher wäre es schön, wenn die Wahl auf eine Sprache fällt, die gut
> dokumentiert ist, wo es gute anschauliche beispiele gibt und die recht
> universell verwendbar wäre.
> Ohne dass sie dabei konzeptionell ungeeignet sein darf für "den
> Zugriff auf den Baum".
Schwierig. Ich wuerde den eigentlichen Programmierteil (Java, perl,
PHP, python, Ruby, ...) getrennt sehen von der Manipulation der
XML-Dokumente (laeuft IMHO auf XSLT raus). Man kann z.B. einen
Programm/Webservice in Java schreiben, und darin XSLT-Aufrufe
einbauen, um "mal schnell" ein XML-Dokument zu transformieren, und das
Ergebnis wieder in java zu haben. Das geht mit RR sicher auch.
Die zu klaerende Frage waere allerdings auch, wieviel
Drumrum-Programmierung in Java etc. Du eigentlich brauchst.
Wolfgang
Andreas Borutta
>>> Erweiterung der XHTML-DTD wuerde bedeuten dass Du neue Begriffe
>>> zu XHTML hinzufuegen wolltest (aehm: Problem: kein Browser versteht sie)?
>>
>> Was meinst Du hier mit "verstehen" bitte?
>
> Dass es fuer den Browser (und die Darstellung) keine Semantik hat.
OK, dachte ich mir.
>> Wenn die DTD wirksam ergänzt wurde, "weiß" der Browser - in Verbindung
>> mit dem CSS - wie er die Elemente darzustellen hat.
>
> Da musst Du noch klaeren, was genau Du alles haben willst. Einer der Vorteile
> von XML ist, dass man verschiedene Teilsprachen ja mischen kann.
Genau das würde mir gefallen. Aber mir ist noch nicht klar, wie man
/praxistauglich/ Dokumente in einem Gemisch aus XHTML und XML (für
welches man selber eine DTD verfasst hat) bereitstellt.
> * HTML (das existierende, das allen Browsern bekannt ist)
> * Annotationen, die Du im CSS auch beruecksichtigst, und die auch Einfluss
> auf die Darstellung des Dokuments selber haben
> (vielleicht <keyword>...</keyword>, was dann rot gedruckt wird, und aber auch
> in einen Index aufgenommen wird)
> * Annotationen, die nur der Dokumentverwaltung und Verknuepfung dienen, aber
> in der direkten Darstellung nicht auftreten, vielleicht
> <annotation>das habe ich von XY, irgendwie ist es zweifelhaft</annotation>
> was man dann auch mit HTML-Struktur mischen kann
> <table themengebiet="bla"/>...</table>
>
>>> Oder willst Du nur weitere, eigene Attribute in ein XHTML-Dokument
>>> einfuegen, die keine Semantik fuer den Browser haben, sondern nur
>>> fuer Deine Dokumentverwaltung?
>>
>> Nein, es geht mir vorrangig um Elemente.
>> <interview></interview>
>> statt
>> <div id="interview"></div>
>> um mal ein sehr einfaches Beispiel zu nennen.
>
> Ah, OK, das waere der 2. Fall von oben.
Richtig.
>> Aber es ist natürlich richtig: eine Semantik haben die Elemente für
>> den Browser nicht.
>> Aber die hat
>> <div id="interview"></div>
>> auch nicht.
>
> Mit CSS kannst Du ihnen die aber ja in gewisser Weise zuordnen.
Ich denke man kann nicht im engen Sinn von Zuordnung sprechen, weil
Gestaltmerkmale nicht in einer formalen Weise einer Bedeutung
zugeordnet werden.
Ein Autoren-CSS transportiert letztlich nicht mehr als einen Vorschlag
zur Gestaltung.
Prima wäre eine Methode, die es erlaubt, für selbstgeschriebene
Elemente (wir sind immer noch einem Dokument, welches aus XHTML+XML
besteht) festzulegen "Behandele dieses Element semantisch wie das
Element H2.
Und: Falls das Autoren-CSS nicht bereitsteht, verwende als Fallback
das Browserstylesheet und die Regeln für H2.
> Bzw.
> nicht direkt fuer den Browser, sondern erstmal fuer die CSS-Ebene
> (Darstellungsebene), die ihnen eine Semantik gibt, die der Browser
> versteht. Ohne CSS wuerde der Browser sie einfach ignorieren. Kommt
> halt drauf an, was Du machen willst.
>
>>> Letzeres geht ohne Probleme,
>>> z.B. <xhtml:table my:comment="tabelle zu bla">... </>
>>> Dazu sind de unterschiedlichen namespaces ja da.
>>
>> Namespaces muss ich mir noch genauer anschauen.
>> Vermutlich mindert ihre Verwendung jedoch die Lesbarkeit von Code
>
> wenig. Du kannst XHTML als default-Namespace nehmen (die Elemente
> heissen dann unveraendert <b> usw.), und "eigene" Namespaces
> nur kurz im Header deklarieren xmlns:my="http://bla/meineannotationen"
> (die URL muss nicht sinnvoll sein, in HTML ist sie nur ein String)
> und dann mit <my:annotation>...</my:annotation> arbeiten.
Hhmm.
Schön sind Elementnamen mit so einem Präfix und Doppelpunkt als
Trenner nicht.
> Der Vorteil ist, dass jeder, der mit der Software mal arbeiten muss,
> oder Dokumente dazu erstellt, auch gleich erkennt welche Tags HTML
> sind, und welche einen anderen, eigenen Aufgabenbereich haben.
Ich verstehe das Argument. Aber sowas könnte man doch dem Editor
überlassen.
Der würde einfach für jedes Element die entsprechende DTD anzeigen.
> Wichtig koennte das auch werden, wenn Du mal mit jemandem anderen
> Dokumente austauschen willst. Und es ist auch fuer Software
> einfacher, die Aufgabenbereiche auseinanderzuhalten (siehe unten (*)).
Ich antworte unten.
>> Zum Beispiel verbietet es sich im Hinblick auf Barrierearmut eigene
>> Elemente für Überschriften zu verwenden.
>
> Das spraeche fuer die Wahl, alle Annotationen in Attribute zu verlagern.
> <table themengebiet="bla"/>...</table>
Es geht nicht nur um "Annotationen".
Es geht mir um gut lesbare, sprechende Elementnamen.
Möglichst selten mit Attributen.
Vielleicht kann man es plakativ so ausdrücken:
Container ohne Bedeutung wie span und div, sowie selbst erfundene
Werte für class- bzw. id-Attribute werden ersetzt durch Elemente.
Andere XHTML-Elemente werden nur sehr zurückhaltend ersetzt, weil dies
mit einem Verlust an Semantik einhergeht.
> Allerdings: muss das Original-Dokument (das sowohl Inhalt als auch
> Metainformationen enthaelt) barrierearm sein (aus meiner Sicht nicht)?
Aus meiner Sicht auch nicht.
Ich beziehe den Begriff "Barrierearm" auf die Wirkung eines Dokumentes
in der Praxis - also bei der Verwendung durch verschiedenste Nutzer
mit mit realen, typischerweise verwendeten Clients.
> Du willst doch sowieso mit XSLT oder sonstwie die auszuliefernden
> Dokumente (und Uebersichtsseiten, Sammlungen, Verlinkungen etc)
> erzeugen. Dort muessen die Annotationen ja garnicht drin sein. Das
> kann reines XHTML sein.
Eigentlich möchte ich genau das nicht pauschal tun - für jedes
Element.
Nur wenn es wirklich starke Gründe dafür gibt.
>> Screenreader interpretieren solche Elemente nicht als Überschrift und
>> versagen somit ihren Nutzern Hilfstechniken, wie z.B. das Hangeln
>> durch die Überschriftenstruktur.
>
> Deswegen sollte man an sich nicht die XHTML-DTD "erweitern", sondern
> seine eigenen Angelegenheiten in separaten Namespaces getrennt halten
> (Bezug zu oben (*)). Und dann XHTML generieren, wobei man die
> Annotationen verwendet um zu steuern was man generiert.
Mein Ziel ist besser lesbarer und von technischen Metainformationen
weithin befreiter Quellcode.
Dieses Ziel müsste ich dann opfern.
Die Namespaces-Präfixe verschlechtern die Lesbarkeit deutlich.
Nochmal ein Beispiel, was mir vorschwebt:
Eine XHTML-DTD.
Eine Andreas-DTD.
Ein Dokument mit Elementen aus beiden DTDs.
<h1>...</h1>
<p>...</p>
<interview>
<frage>
<sprecher>...</sprecher>
...
</frage>
<antwort>
<sprecher>...</sprecher>
...
</antwort>
<frage>
<sprecher>...</sprecher>
...
</frage>
<antwort>
<sprecher>...</sprecher>
...
</antwort>
</interview>
<p>...</p>
Nochmal herzlichen Dank für Deine Kommentare und Hinweise.
Ich kann selber gar nicht abschätzen, ob ich Programmlösungen
benötigen werde, die sich mit XSLT nur schwer oder auf unpassende,
zähe Weise lösen lassen.
Es erscheint mir jedoch wenig realistisch, zwei Sprachen zu erlernen,
die sich noch dazu recht stark im Wesen unterscheiden.
Vielleicht sollte Ruby-Programmierer fragen, wie gut man mit ihrer
Sprache auf den Elementebaum zugreifen kann und sie um ein Beispiel
bitten.
Andreas
--
http://borumat.de
Stefan Froehlich
> > Einer der Vorteile von XML ist, dass man verschiedene
> > Teilsprachen ja mischen kann.
> Genau das würde mir gefallen. Aber mir ist noch nicht klar, wie
> man /praxistauglich/ Dokumente in einem Gemisch aus XHTML und XML
> (für welches man selber eine DTD verfasst hat) bereitstellt.
Nicht.
Also, das ist so natuerlich falsch. Aber ich ahne, was Du damit tun
willst (naemlich das Zeug wenigstens zum Teil per Hand schreiben),
und ich kann Dir aus Erfahrung sagen, dass XML mit Namespaces zwar
noch leidlich gut lesbar ist, wenn man ausgeschlafen ist und wenn
der Autor des Dokuments beim Schreiben nicht voellig abgedreht war,
aber das Erstellen solcher Dokumente ist einfach nur: grauslich.
XML und Namespaces sind sagenhaft praktisch, wenn man irgendwo einen
Standard hat, aus dem man Teile wiederverwerten will (und auf diese
Weise dann auch tatsaechlich kann). Aber im groesseren Stil anwenden
moechte man das nur bei automatisch generiertem und automatisch
ausgewertetem Kontext.
Servus,
Stefan
--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike
Für grose Genießer: Stefan - wenn alles gelingt!
(Sloganizer)
Andreas Borutta
>>> Einer der Vorteile von XML ist, dass man verschiedene
>>> Teilsprachen ja mischen kann.
>
>> Genau das würde mir gefallen. Aber mir ist noch nicht klar, wie
>> man /praxistauglich/ Dokumente in einem Gemisch aus XHTML und XML
>> (für welches man selber eine DTD verfasst hat) bereitstellt.
>
> Nicht.
>
> Also, das ist so natuerlich falsch. Aber ich ahne, was Du damit tun
> willst (naemlich das Zeug wenigstens zum Teil per Hand schreiben),
Du ahnst richtig :)
Das Schreiben von Hand wäre sogar der Standardfall.
Kürzlich habe ich das erste Mal einen XML-Editor ausprobiert und war
sehr angetan von dessen Möglichkeiten.
On-the-fly wurde die Validität und Wohlgeformtheit des Codes geprüft.
Kontextabhängig wurden nur diejenigen Elemente zum "Weiterschreiben"
angeboten, die gemäß DTD erlaubt sind.
Die Arbeit mit Tastenkürzel wird umfassend unterstützt.
Es gab neben der normalen Quellcode-Ansicht zwei weitere Ansichten,
die die Eingabe von Inhalten erleichtern, wie z.B. eine sog.
Grid-Ansicht oder auch eine tabellarische Ansicht.
So kann man hervorragend arbeiten.
> und ich kann Dir aus Erfahrung sagen, dass XML mit Namespaces zwar
> noch leidlich gut lesbar ist, wenn man ausgeschlafen ist und wenn
> der Autor des Dokuments beim Schreiben nicht voellig abgedreht war,
> aber das Erstellen solcher Dokumente ist einfach nur: grauslich.
Damit bestätigst Du meine Ahnung.
Ich hatte das in einem Reply auf ein Posting von Wolfgang auch schon
so geäußert.
> XML und Namespaces sind sagenhaft praktisch, wenn man irgendwo einen
> Standard hat, aus dem man Teile wiederverwerten will (und auf diese
> Weise dann auch tatsaechlich kann). Aber im groesseren Stil anwenden
> moechte man das nur bei automatisch generiertem und automatisch
> ausgewertetem Kontext.
Da es nicht erlaubt ist, mehrere DTDs einzubinden:
| <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
| "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
| <!DOCTYPE html SYSTEM "/custom.dtd">
Gibt es einen praxistauglichen Weg, XHTML-Elemente /und/ eigene
Elemente im ausgelieferten Dokument zu verwenden?
Andreas
Daniel Urban
[...]
> An python finde ich das Merkmal "Leeraum ist Teil der Syntax" sehr
> attraktiv.
Ich finde es das schlimmste an Python. Ich kenne zwar auch Leute, die damit
leben können, aber dass es wirklich jemand attraktiv findet, habe ich selten
gehört.
> Denkst du, dass man mit Python ebenfalls auf "gute Weise" auf den Baum
> zugreifen kann um bestimmte Manipulationen - siehe mein bereits
> gepostetes Beispiel zur Sitemap - vorzunehmen?
Ich verwende in einem Projekt aus historischen Gründen Python zur Code- und
Dokumentengenerierung. Es gibt für Python auch APIs für XML. Möglich ist es
also.
[...]
> Hintergrund meiner Frage:
> Ohne Koketterie weiß ich von mir, dass meine Begabung nicht im
> erlernen des Programmierens liegt. Das fällt mir schwer.
Ich hätte eigentlich gedacht, dass Du Dich für XSLT entschieden hättest.
Dann brauchst Du nur XSLT lernen. Einen entsprechenden Prozessor sollte man
auch als Batch-Skript ausführen können, ohne ihn in eine andere
Programmiersprache einbetten zu müssen.
> Daher wäre es schön, wenn die Wahl auf eine Sprache fällt, die gut
> dokumentiert ist, wo es gute anschauliche beispiele gibt und die recht
> universell verwendbar wäre.
Die gängigen Programmiersprachen sind auch dokumentiert. Wenn die
Programmiersprache weit ververbreitet ist, liefert Google auch für fast
alles eine Antwort.
> Ohne dass sie dabei konzeptionell ungeeignet sein darf für "den
> Zugriff auf den Baum".
Was heisst in diesem Zusammenhang "ungeeignet". Gehen wird es in jeder
universellen Programmiersprache, sonst wäre sie wohl auch nicht universell.
Gruß,
Daniel
Daniel Urban
[Programmiersprachenwahl]
> Damit kenne ich ich wenig aus. Mit python habe ich nur ganz kurz mal
> was gebastelt. Von Ruby on Rails schwaermen einige Leute, und die
> Argumente erschienen mir plausibel. Man sollte was nehmen, was man
> kann, was hoffentlich auch Leute, die an dem Projekt mitarbeiten,
> koennen (also nix exotisches). Und nix ungeeignetes.
In der Theorie sollte man die Programmiersprache wählen, die das Problem an
besten lösen kann. In der professionellen Praxis wird man die
Programmiersprache wählen, mit der man das Problem am kostengünstigsten
lösen kann. Der Hobby-Programmierer wird die Wahl der Programmiersprache
wohl eher an seinen persönlichen Interessen/Fähigkeiten ausrichten.
Gruß,
Daniel
Daniel Urban
[...]
> Kürzlich habe ich das erste Mal einen XML-Editor ausprobiert und war
> sehr angetan von dessen Möglichkeiten.
> On-the-fly wurde die Validität und Wohlgeformtheit des Codes geprüft.
> Kontextabhängig wurden nur diejenigen Elemente zum "Weiterschreiben"
> angeboten, die gemäß DTD erlaubt sind.
> Die Arbeit mit Tastenkürzel wird umfassend unterstützt.
>
> Es gab neben der normalen Quellcode-Ansicht zwei weitere Ansichten,
> die die Eingabe von Inhalten erleichtern, wie z.B. eine sog.
> Grid-Ansicht oder auch eine tabellarische Ansicht.
Das sind mittlerweile wohl alles Standard-Features von gängigen
XML-Editoren.
> So kann man hervorragend arbeiten.
Nur so kann man wirklich arbeiten.
[...]
> Da es nicht erlaubt ist, mehrere DTDs einzubinden:
>
> | <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
> | "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
> | <!DOCTYPE html SYSTEM "/custom.dtd">
>
> Gibt es einen praxistauglichen Weg, XHTML-Elemente /und/ eigene
> Elemente im ausgelieferten Dokument zu verwenden?
Mit XSDs müsste das AFAIR möglich sein, aber dann auch nur mit getrennten
Namespaces. Also zwei Techniken, die Du nicht einsetzen willst.
Gruß,
Daniel
Wolfgang May
> Wolfgang May schrieb:
ich nehme das mal zuerst auf:
> Vielleicht kann man es plakativ so ausdrücken:
>
> Container ohne Bedeutung wie span und div, sowie selbst erfundene
> Werte für class- bzw. id-Attribute werden ersetzt durch Elemente.
>
> Andere XHTML-Elemente werden nur sehr zurückhaltend ersetzt, weil dies
> mit einem Verlust an Semantik einhergeht.
Ich wuerde es etwa so aufbauen: Du hast zum einen die "Original-Dokumente",
die die Terminologie <html:h1>, <html:h2>, <a:tabelle>
<a:interview interviewter="Karl Napf" datum="1.1.2010">
<a:kommentar>anlaesslich <em>gaga</em> und <em>bla</em></a:kommentar>
<!-- im kommentar kann auch optisches HTML-Markup enthalten sein -->
<a:frage>...</a:frage> <a:antwort>...</a:antwort>
</a:interview>
etc benutzen.
(ich lasse die namespaces absichtlich mal dabei, um Dir den Nutzen davon
anzudeuten)
Diese willst Du jetzt (i) lesbar (als XHTML) bereitstellen, und zum anderen
(ii) evtl auch Listen von Tabellen, Interview etc machen und bereitstellen.
Beides sind Transformationen bzw Anfragen ueber den vorhandenen Dokumenten.
Fuer (i) wirfst Du ein "klassisches" XSLT-Stylesheet an, das Deine Elemente
durch Standard-HTML-Markup ersetzt und dabei auch die Metadaten geeignet
einbaut u.a. mit
<xsl:template match="h1|h2|h3">
<xsl:copy-of select="."/>
<xsl:apply-templates select="*"/> <!-- das wendet jetzt templates nacheinander auf
alle Kindelemente, also p,h2,h3,interview etc -->
</xsl:template>
<xsl:template match="a:interview">
<html:h2> Interview mit
<b><xsl:value-of select="@interviewter"/><b> am <xsl:value-of select="@datum"/>
</html:h2>
<xsl:apply-templates select="*"/> <!-- das wendet jetzt templates nacheinander auf
alle Kindelemente also frage-antwort-frage-antwort ... an -->
</xsl:template>
<xsl:template match="a:frage|a:antwort">
<b><xsl:if test="name()='frage'">Frage:</xsl:if>
<xsl:if test="name()='antwort'">Antwort:</xsl:if> </b>
<xsl:copy-of select="text()|*"/> <br/>
<!-- das xsl:copy-of kopiert alle textknoten und markupknoten, also auch z.B.
und dann habe ich ihm gesagt, er soll jetzt <em>da</em> hinschauen
</xsl:template>
und es gibt ein XHTML-only-Dokument aus.
Wenn Du eine neue Klasse <a:sonstwas> aufnehmen willst, musst Du nur ein passendes
Template erstellen, das angibt, wie diese nach HTML abgebildet wird.
Fuer (ii) wirfst Du ein Skript (bei mir waere das make+saxon-XSLT) an, das ueber
alle Dokumente laeuft, nach
//a:interview
-Elementen sucht, deren Metadaten zugreift und daraus eine XHTML-Liste mit Hyperlinks
auf die einzelnen Beitraege erstellt.
der Vorteil ist, dass Du jederzeit
- neue Funktionalitaet in Form weiterer Aufbereitung wie in (i), z.B. export nach
LaTeX oder ODF bzw OOXML (die Formate die Open Office bzw MS Office zugrundeliegen)
- neue Listen
- neue Klassen von Objekten
hinzunehmen kannst, und auch die alten relativ einfach und lokal ueberarbeiten kannst.
> >> Wenn die DTD wirksam ergänzt wurde, "weiß" der Browser - in Verbindung
> >> mit dem CSS - wie er die Elemente darzustellen hat.
> >
> > Da musst Du noch klaeren, was genau Du alles haben willst. Einer der Vorteile
> > von XML ist, dass man verschiedene Teilsprachen ja mischen kann.
>
> Genau das würde mir gefallen. Aber mir ist noch nicht klar, wie man
> /praxistauglich/ Dokumente in einem Gemisch aus XHTML und XML (für
> welches man selber eine DTD verfasst hat) bereitstellt.
siehe oben. Man kann in einem Dokument beide mischen.
Das Problem, was Du in einem spaeteren Posting noch andeutest, ist, dass Du
fuer Deine Tools nur eine DTD haben kannst. Das wuerde bedeuten, die namespaces
und Praefixe dann doch wegzulassen (aber in Gedanken dabeizubleiben, dass es eigentlich
zwei Teilsprachen sind).
> >> Aber es ist natürlich richtig: eine Semantik haben die Elemente für
> >> den Browser nicht.
> >> Aber die hat
> >> <div id="interview"></div>
> >> auch nicht.
> >
> > Mit CSS kannst Du ihnen die aber ja in gewisser Weise zuordnen.
>
> Ich denke man kann nicht im engen Sinn von Zuordnung sprechen, weil
> Gestaltmerkmale nicht in einer formalen Weise einer Bedeutung
> zugeordnet werden.
> Ein Autoren-CSS transportiert letztlich nicht mehr als einen Vorschlag
> zur Gestaltung.
Ja genau, das meinte ich mit "in gewisser Weise". Semantik ist CSS ja
sowieso nicht wirklich, sondern nur Darstellungsinformationen.
> Prima wäre eine Methode, die es erlaubt, für selbstgeschriebene
> Elemente (wir sind immer noch einem Dokument, welches aus XHTML+XML
> besteht) festzulegen "Behandele dieses Element semantisch wie das
> Element H2.
> Und: Falls das Autoren-CSS nicht bereitsteht, verwende als Fallback
> das Browserstylesheet und die Regeln für H2.
Das ist im Prinzip das, was ich in das unter (i) beschriebene
XSLT-Stylesheet reinbauen wuerde. Dann wird XHTML ausgeliefert und so
dargestellt wie es ist.
<interview> ist dabei die Terminologie, die Du auf Deiner Seite im
Dokument benutzt, <h2>, mit Gestaltung der Ueberschrift aus den
Metadaten ueber das Interview, ist das was Du gedruckt bzw am
Browser auslieferst.
> > wenig. Du kannst XHTML als default-Namespace nehmen (die Elemente
> > heissen dann unveraendert <b> usw.), und "eigene" Namespaces
> > nur kurz im Header deklarieren xmlns:my="http://bla/meineannotationen"
> > (die URL muss nicht sinnvoll sein, in HTML ist sie nur ein String)
> > und dann mit <my:annotation>...</my:annotation> arbeiten.
>
> Hhmm.
> Schön sind Elementnamen mit so einem Präfix und Doppelpunkt als
> Trenner nicht.
Daran gewoehnt man sich, und ist irgendwann froh darueber dass sie die
Trennung der Aspekte (semantische Struktur des Inhalts als Interviews
etc. vs reines Markup) deutlich machen.
> > Der Vorteil ist, dass jeder, der mit der Software mal arbeiten muss,
> > oder Dokumente dazu erstellt, auch gleich erkennt welche Tags HTML
> > sind, und welche einen anderen, eigenen Aufgabenbereich haben.
>
> Ich verstehe das Argument. Aber sowas könnte man doch dem Editor
> überlassen.
> Der würde einfach für jedes Element die entsprechende DTD anzeigen.
Daraus wuerde der Bearbeiter aber nicht notwendigerweise erkennen,
welche Tags jetzt HTML sind (vielleicht welche, die er sonst garnicht
kennt/benutzt) und welche "eigene" sind.
> >> Zum Beispiel verbietet es sich im Hinblick auf Barrierearmut eigene
> >> Elemente für Überschriften zu verwenden.
> >
> > Das spraeche fuer die Wahl, alle Annotationen in Attribute zu verlagern.
> > <table themengebiet="bla"/>...</table>
>
> Es geht nicht nur um "Annotationen".
>
> Es geht mir um gut lesbare, sprechende Elementnamen.
> Möglichst selten mit Attributen.
Zur Verwaltung wirst Du mit der Zeit einiges finden, was Du gerne in Attributen
noch unterbringst, um dann z.B. alle INtervioews mit XY,
oder alle zwischen zwei bestimmten Zeitpunkten zu finden und zu ordnen.
> > Allerdings: muss das Original-Dokument (das sowohl Inhalt als auch
> > Metainformationen enthaelt) barrierearm sein (aus meiner Sicht nicht)?
>
> Aus meiner Sicht auch nicht.
> Ich beziehe den Begriff "Barrierearm" auf die Wirkung eines Dokumentes
> in der Praxis - also bei der Verwendung durch verschiedenste Nutzer
> mit mit realen, typischerweise verwendeten Clients.
OK, also intern eigene DTD benutzen und reines XHTML ausliefern.
> > Du willst doch sowieso mit XSLT oder sonstwie die auszuliefernden
> > Dokumente (und Uebersichtsseiten, Sammlungen, Verlinkungen etc)
> > erzeugen. Dort muessen die Annotationen ja garnicht drin sein. Das
> > kann reines XHTML sein.
>
> Eigentlich möchte ich genau das nicht pauschal tun - für jedes
> Element.
>
> Nur wenn es wirklich starke Gründe dafür gibt.
Die Elemente mit Deinen "sprechenden" Elementnamen musst Du
transformieren. Die HTML-Markup-Elemente nicht, die kannst Du jeweils
kopieren (mit XSLT wie oben gezeigt auch schichtweise, dass ggf darin
enthaltene eigene Elemente dann doch wieder transformiert werden).
> > Deswegen sollte man an sich nicht die XHTML-DTD "erweitern", sondern
> > seine eigenen Angelegenheiten in separaten Namespaces getrennt halten
> > (Bezug zu oben (*)). Und dann XHTML generieren, wobei man die
> > Annotationen verwendet um zu steuern was man generiert.
>
> Mein Ziel ist besser lesbarer und von technischen Metainformationen
> weithin befreiter Quellcode.
technische (im Sinn von optischem Markup) bekommst Du ganz raus, wenn
Du sie ins XSLT-Stylesheet verlagerst. Die anderen (Interviewter,
Datum, Kommentar) betrachte ich als semantische Metainformationen, da
ist es IMHO sinnvoll, sie im Dokument mit abzulegen um auch die
Dokumente gemeinsam verwalten und ggf selektiert und geordnet
bereitstellen zu koennen.
> Dieses Ziel müsste ich dann opfern.
> Die Namespaces-Präfixe verschlechtern die Lesbarkeit deutlich.
Ich sehe aus Deinem anderen Posting, dass Du sie wohl weglassen musst.
Wolfgang
Wolfgang May
> > Also, das ist so natuerlich falsch. Aber ich ahne, was Du damit tun
> > willst (naemlich das Zeug wenigstens zum Teil per Hand schreiben),
>
> Du ahnst richtig :)
>
> Das Schreiben von Hand wäre sogar der Standardfall.
>
> Kürzlich habe ich das erste Mal einen XML-Editor ausprobiert und war
> sehr angetan von dessen Möglichkeiten.
> On-the-fly wurde die Validität und Wohlgeformtheit des Codes geprüft.
> Kontextabhängig wurden nur diejenigen Elemente zum "Weiterschreiben"
> angeboten, die gemäß DTD erlaubt sind.
> Die Arbeit mit Tastenkürzel wird umfassend unterstützt.
>
> Es gab neben der normalen Quellcode-Ansicht zwei weitere Ansichten,
> die die Eingabe von Inhalten erleichtern, wie z.B. eine sog.
> Grid-Ansicht oder auch eine tabellarische Ansicht.
>
> So kann man hervorragend arbeiten.
Sehe ich fuer Deine Situation auch so. Fuer Vollzeitprogrammierer
gibts deutlich leistungsfaehigere Tools, aber mit entsprechendem
erstmaligem Einarbeitungsaufwand, und wenn man die dann nicht
regelmaessig 8 Stunden an 5 Tagen in der Woche nutzt, entwickelt
man auch nicht so richtig die Bindung und Routine daran.
> > XML und Namespaces sind sagenhaft praktisch, wenn man irgendwo einen
> > Standard hat, aus dem man Teile wiederverwerten will (und auf diese
> > Weise dann auch tatsaechlich kann). Aber im groesseren Stil anwenden
> > moechte man das nur bei automatisch generiertem und automatisch
> > ausgewertetem Kontext.
>
> Da es nicht erlaubt ist, mehrere DTDs einzubinden:
>
> | <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
> | "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
> | <!DOCTYPE html SYSTEM "/custom.dtd">
>
> Gibt es einen praxistauglichen Weg, XHTML-Elemente /und/ eigene
> Elemente im ausgelieferten Dokument zu verwenden?
Dann musst Du es doch hemdsaermelig machen:
XHTML-DTD kopieren, und Deine Elemente dazunehmen, und in die rein
wieder HTML-Markup zulassen.
Etwa so:
Dort wo jetzt in HTML
<!ELEMENT ??? (..., h2, ...)>
ist,
<!ELEMENT ??? (..., h2, interview, ...)>
ergaenzen, und dann etwa
<!ELEMENT interview (kommentar, (frage,antwort)+)>
<!ELEMENT kommentar (passendes HTML-markup als mixed)>
<!ELEMENT frage (passendes HTML-markup als mixed)>
<!ELEMENT antwort (passendes HTML-markup als mixed)>
Schau Dir Parameter-Entities an, dann kannst Du "passendes HTML-markup
als mixed" einmal als Makro definieren, und dann immer wieder verwenden.
Wolfgang
Wolfgang May
> "Wolfgang May"
> [Programmiersprachenwahl]
> > Damit kenne ich ich wenig aus. Mit python habe ich nur ganz kurz mal
> > was gebastelt. Von Ruby on Rails schwaermen einige Leute, und die
> > Argumente erschienen mir plausibel. Man sollte was nehmen, was man
> > kann, was hoffentlich auch Leute, die an dem Projekt mitarbeiten,
> > koennen (also nix exotisches). Und nix ungeeignetes.
>
> In der Theorie sollte man die Programmiersprache wählen, die das Problem an
> besten lösen kann. In der professionellen Praxis wird man die
> Programmiersprache wählen, mit der man das Problem am kostengünstigsten
> lösen kann.
Was meistens mittelfristig gerechnet auch diejenige sein wird, die das
Problem an besten lösen kann.
Das wird allerdings tatsaechlich an vielen Stellen nicht erkannt bzw
verdraengt weil man die Anfangsinvestition scheut. Der Programmierungs-
und Wartungsaufwand (oft auch durch fehlerbedingte Ausfaelle) ist
allerdings dann in jedem Jahr deutlich hoeher.
> Der Hobby-Programmierer wird die Wahl der Programmiersprache
> wohl eher an seinen persönlichen Interessen/Fähigkeiten ausrichten.
Dann wuerde ich heute noch mit der Kinderschaufel den Garten umgraben
und das Gartenhaeuschen aus Lego bauen. In fast jedem Bereich ist es
auch fuer Amateure voellig selbstverstaendlich, sich nach geeigneten
Mitteln umzuschauen und diese dann zu erlernen und anzuwenden. Ich
verstehe nicht, warum das beim Programmieren nicht so ist. Dort ist man
ja noch der Held wenn man alles in C++/perl/php/sonstwas "loesen"
(nein, runterhacken) kann.
Wolfgang
Andreas Borutta
>>> XML und Namespaces sind sagenhaft praktisch, wenn man irgendwo einen
>>> Standard hat, aus dem man Teile wiederverwerten will (und auf diese
>>> Weise dann auch tatsaechlich kann). Aber im groesseren Stil anwenden
>>> moechte man das nur bei automatisch generiertem und automatisch
>>> ausgewertetem Kontext.
>>
>> Da es nicht erlaubt ist, mehrere DTDs einzubinden:
>>
>>| <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
>>| "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
>>| <!DOCTYPE html SYSTEM "/custom.dtd">
>>
>> Gibt es einen praxistauglichen Weg, XHTML-Elemente /und/ eigene
>> Elemente im ausgelieferten Dokument zu verwenden?
>
> Dann musst Du es doch hemdsaermelig machen:
> XHTML-DTD kopieren, und Deine Elemente dazunehmen, und in die rein
> wieder HTML-Markup zulassen.
>
> Etwa so:
> Dort wo jetzt in HTML
> <!ELEMENT ??? (..., h2, ...)>
> ist,
> <!ELEMENT ??? (..., h2, interview, ...)>
> ergaenzen, und dann etwa
> <!ELEMENT interview (kommentar, (frage,antwort)+)>
> <!ELEMENT kommentar (passendes HTML-markup als mixed)>
> <!ELEMENT frage (passendes HTML-markup als mixed)>
> <!ELEMENT antwort (passendes HTML-markup als mixed)>
An diese Methode hatte ich zuerst auch gedacht, aber gleich
befürchtet, dass Browser ohne
http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd
im Header "Probleme bereiten".
Falls jemand von Problemen weiß, bitte Laut geben.
Wenn jemand einen vollständigen, praxistauglichen Dokument-Kopf posten
möchte: gerne.
> Schau Dir Parameter-Entities an, dann kannst Du "passendes HTML-markup
> als mixed" einmal als Makro definieren, und dann immer wieder verwenden.
Yep.
Gestern ist hier frisch aus GB eingetroffen:
Devoping SGML DTDs.
Eve Maler und Jeanne el Andaloussi.
From text to model to markup.
ISBN 0-13-309881-8
Klasse geschrieben, meinem ersten Eindruck nach.
Andreas
--
http://borumat.de
Daniel Urban
>> In der Theorie sollte man die Programmiersprache wählen, die das Problem
>> an
>> besten lösen kann. In der professionellen Praxis wird man die
>> Programmiersprache wählen, mit der man das Problem am kostengünstigsten
>> lösen kann.
>
> Was meistens mittelfristig gerechnet auch diejenige sein wird, die das
> Problem an besten lösen kann.
Nicht immer, weil man wie Du zurecht angemerkt hast, ggf. kein Know-how in
diesem Bereich hat und daher den Einarbeitungsaufwand spart, in dem man eine
weniger geeignete Programmiersprache wählt. Wenn das Problem also nur
punktuell auftritt, wird der Grenzwert, nicht erreicht, ab dem es sich
rechnen würde, Know-how aufzubauen.
Der zweite und wesentlichere Faktor sind die Abstimmungskosten, die sich
natürlich erhöhen, wenn man unterschiedliche Programmiersprachen einsetzt,
weil man Teilprobleme mit den dafür geeigneten Programmiersprachen lösen
will.
> Das wird allerdings tatsaechlich an vielen Stellen nicht erkannt bzw
> verdraengt weil man die Anfangsinvestition scheut.
Möglich, aber oft besteht das Problem darin, dass die Investition sich nicht
rechnen würde. Eine hetrogene Programmiersprachenlandschaft kann recht teuer
werden.
> Der Programmierungs-
> und Wartungsaufwand (oft auch durch fehlerbedingte Ausfaelle) ist
> allerdings dann in jedem Jahr deutlich hoeher.
Nein, nicht zwingend. Immerhin muss man ggf. Know-how aufbauen, welches man
sonst nicht anders verwenden kann. Das kann die Kostenrelation schon
erhöhen. In diesem konrekten Fall (XML, XSLT) ist das aber relativ
unwahrscheinlich.
>> Der Hobby-Programmierer wird die Wahl der Programmiersprache
>> wohl eher an seinen persönlichen Interessen/Fähigkeiten ausrichten.
>
> Dann wuerde ich heute noch mit der Kinderschaufel den Garten umgraben
> und das Gartenhaeuschen aus Lego bauen. In fast jedem Bereich ist es
> auch fuer Amateure voellig selbstverstaendlich, sich nach geeigneten
> Mitteln umzuschauen und diese dann zu erlernen und anzuwenden.
In der Theorie ist dem vielleicht so, aber viele (nicht alle) haben es sich
in dem Bereich, den sie kontrollieren können gut eingerichtet und werden
auch zunächst versuchen, die Probleme mit diesen Mitteln zu bewältigen. Erst
wenn sie dort einen Grad an Frustration überschritten haben, werden sie nach
Dingen suchen, mit denen sie das Problem besser lösen können. Aber auch
dabei werden sie darauf achten, dass es bekannte und verstandene Konzepte
enthält, weil man ungern alles neu lernt.
> Ich
> verstehe nicht, warum das beim Programmieren nicht so ist.
Das ist IMHO kein besonderes Problem der Programmierung, sondern eine
generelle menschliche Eigenschaft, die nur von einer kleineren Gruppe von
neugierigen Ausprobierern durchbrochen wird. Bei den anderen dauert es dann
deutlich länger, bis sie Dinge ebenfalls annehmen.
Gruß,
Daniel
Wolfgang May
> Wolfgang May schrieb:
> > Dann musst Du es doch hemdsaermelig machen:
> > XHTML-DTD kopieren, und Deine Elemente dazunehmen, und in die rein
> > wieder HTML-Markup zulassen.
> >
> > Etwa so:
> > Dort wo jetzt in HTML
> > <!ELEMENT ??? (..., h2, ...)>
> > ist,
> > <!ELEMENT ??? (..., h2, interview, ...)>
> > ergaenzen, und dann etwa
> > <!ELEMENT interview (kommentar, (frage,antwort)+)>
> > <!ELEMENT kommentar (passendes HTML-markup als mixed)>
> > <!ELEMENT frage (passendes HTML-markup als mixed)>
> > <!ELEMENT antwort (passendes HTML-markup als mixed)>
>
> An diese Methode hatte ich zuerst auch gedacht, aber gleich
> befürchtet, dass Browser ohne
> http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd
> im Header "Probleme bereiten".
Fuer das mit meinem im Vorposting in dem mit (i) beschriebenen Schritt
erstellte, ausgelieferte Dokument, das ja reines XHTML waere, kannst Du das
obige sogar so reinschreiben.
Deine Elemente haettest Du dann nur in dem (internen) Ausgangsdokument.
> Falls jemand von Problemen weiß, bitte Laut geben.
Ich wuesste aber nicht, dass das einen HTML-Browser wirklich interessiert:
* Browser kommen auch mit kaputtem HTML zurecht (frueher war fast alles HTML
handgeschrieben, und "kaputt"), z.B.
<table><tr><td>bla<td>foo<tr><td>bla2<td>foo2</table>
Browser ergaenzen das zu dem was richtig waere erwartet. Schliessende Tags,
brauchbare Schachtelung etc.
* Wenn du in dem Ausgangsdokument o.g. W3C-DTD im Header listest,
wird es Dich beim Aufruf eines XSLT-Tools (komplett unerwartet)
auf die Schn**ze hauen (wie mich vor ein paar Wochen, der Thread muesste
noch zugreifbar sein ...).
Das unter der URL beim W3C abgelegte Dokument ist zwar (per Browser)
zugreifbar, aber nicht (mehr) per sonstiger Software.
Loesungen sind entweder mit catalog (siehe o.g. Thread), oder
DTD kopieren, lokal ablegen und ggf auch den Filenamen umbenennen (Du musst
dann einige weitere auch kopieren, um die Umlaut-Definitionen zu haben).
Dabei kannst Du sie auch gleich mit Deinen Elementen erweitern (und
sinnvollerweise dann den Filenamen auch aendern).
> Wenn jemand einen vollständigen, praxistauglichen Dokument-Kopf posten
> möchte: gerne.
Hier siehts so aus:
### file index.xml
<?xml version="1.0" encoding="ISO-8859-1"?>
<?xml-stylesheet type="text/xsl" href="Stylesheets/dbis-general.xsl"?>
<!DOCTYPE html
PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.dbis.informatik.uni-goettingen.de/DTDs/xhtml1-strict.dtd">
usw...
######
Unter der Adresse liegt derzeit eine unveraenderte Kopie der
W3C-DTD, aber da koennte man auch eigene Elemente mit reinpacken und einen
anderen Namen waehlen.
Aus dem Dokument macht dann ein XSLT-Stylesheet das eigentliche index.html,
das dann
####
<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html> ... </html>
#####
ist.
Ich seh grad, was ganz aehnliches wie Du es evtl machen koenntest, habe ich
sogar hier:
http://www.dbis.informatik.uni-goettingen.de/Publics/publication.dtd
Publikationsliste. Eigene Elemente und HTML-Markup gemischt.
Instanz (schon aus einzelnen Dateien aufgesammelt):
http://www.dbis.informatik.uni-goettingen.de/Publics/all_publications.xml
Unter
http://www.dbis.informatik.uni-goettingen.de/Stylesheets/
sind auch ein paar Stylesheets dazu. Damit werden (ansonsten nur kurze
Makefiles, z.B.
http://www.dbis.informatik.uni-goettingen.de/Publics/Makefile
ist das komplexeste davon, weil es aufsammeln muss)
die Webseiten erzeugt.
> > Schau Dir Parameter-Entities an, dann kannst Du "passendes HTML-markup
> > als mixed" einmal als Makro definieren, und dann immer wieder verwenden.
>
> Yep.
> Gestern ist hier frisch aus GB eingetroffen:
>
> Devoping SGML DTDs.
> Eve Maler und Jeanne el Andaloussi.
> From text to model to markup.
> ISBN 0-13-309881-8
>
> Klasse geschrieben, meinem ersten Eindruck nach.
Eve Maler gehoert auf jeden Fall zu den Entwicklern von XML der ersten Stunde.
Falls Du zu XSLT was aehnliches suchst, schau Dir mal "XSLT
Programmers Reference" von Michael Kay an. Ebenfalls ein Urgestein,
und Entwickler des (IMHO eines der besten) Tools "saxon", das
gleichzeitig XSLT und XQuery implementiert und intern auf dieselben
Algorithmen zurueckfuehrt.
Wolfgang
Andreas Borutta
Ich argumentiere ja auch keineswegs pauschal gegen Namespaces.
Es ist nichts weiter als mein eigener Wunsch, die Elementnamen davon
frei zu halten.
Die Elemente aus XHTML kenne ich auswendig. Keine Kunst, das
Vokabularium ist ja sehr übersichtlich.
Auch deshalb benötige ich keine "Erinnerungshilfe", zu welcher Gruppe
ein Element gehört.
> Diese willst Du jetzt (i) lesbar (als XHTML) bereitstellen,
An diesem wesentlichen Punkt muss ich einhaken.
Ich möchte es, wenn es irgendwie machbar ist, eben nicht /prinzipiell/
die "Andreas-Elemente" in XHTML-Elemente (per XSLT) transformieren
(müssen).
Falls das nötig wäre, verlöre die ganze Sache enorm an Attraktivität.
Und nicht zuletzt geht es mir nur um die "Schönheit" des Markups des
lokalen, sondern auch des ausgelieferten Dokumentes.
Danke trotzdem für Dein XSLT-Beispiel.
Vielleicht noch ein Beispiel, wofür ich bewußt XSLT einsetzen möchte.
Auszuliefernder Code:
<a class="pic" title="Größere Version des Bildes anzeigen"
href="bild-1.big.png"><img src="bild-1.png" alt="Lorem" /><img
src="bild-1.png" alt="Lorem" /></a>
Das Class-Attribut ist allein für olle Browser drin, die nicht
vernünftig mit Attributselektoren umgehen können.
Lokaler Code:
<a href="bild-1.big.png"><img src="bild-1.png" alt="Lorem" /></a>
Das Class-Attribut soll also per XSLT hinzugefügt werden.
Es hat kein Existenzrecht im Quelldokument.
Ein alternativer, noch besserer, lokaler Code wäre:
<img src="bild-1.png" alt="Lorem" href="bild-1.big.png" />
[...]
>>>> Wenn die DTD wirksam ergänzt wurde, "weiß" der Browser - in Verbindung
>>>> mit dem CSS - wie er die Elemente darzustellen hat.
>>>
>>> Da musst Du noch klaeren, was genau Du alles haben willst. Einer der Vorteile
>>> von XML ist, dass man verschiedene Teilsprachen ja mischen kann.
>>
>> Genau das würde mir gefallen. Aber mir ist noch nicht klar, wie man
>> /praxistauglich/ Dokumente in einem Gemisch aus XHTML und XML (für
>> welches man selber eine DTD verfasst hat) bereitstellt.
>
> siehe oben. Man kann in einem Dokument beide mischen.
> Das Problem, was Du in einem spaeteren Posting noch andeutest, ist, dass Du
> fuer Deine Tools nur eine DTD haben kannst.
Dann habe ich mich missverständlich ausgedrückt.
Es geht nicht darum, was mein Editor kann oder nicht.
Es geht darum, dass man für ein Wurzelelement nicht einfach zwei DTDs
angeben darf.
Also:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<!DOCTYPE html SYSTEM "custom.dtd">
>>>> Aber es ist natürlich richtig: eine Semantik haben die Elemente für
>>>> den Browser nicht.
>>>> Aber die hat
>>>> <div id="interview"></div>
>>>> auch nicht.
>>>
>>> Mit CSS kannst Du ihnen die aber ja in gewisser Weise zuordnen.
>>
>> Ich denke man kann nicht im engen Sinn von Zuordnung sprechen, weil
>> Gestaltmerkmale nicht in einer formalen Weise einer Bedeutung
>> zugeordnet werden.
>> Ein Autoren-CSS transportiert letztlich nicht mehr als einen Vorschlag
>> zur Gestaltung.
>
> Ja genau, das meinte ich mit "in gewisser Weise". Semantik ist CSS ja
> sowieso nicht wirklich, sondern nur Darstellungsinformationen.
Dann hatte ich Dein "in gewisser Weise" richtig verstanden.
Mein Kommentar war nur als Anmerkung zu verstehen.
>>>> Zum Beispiel verbietet es sich im Hinblick auf Barrierearmut eigene
>>>> Elemente für Überschriften zu verwenden.
>>>
>>> Das spraeche fuer die Wahl, alle Annotationen in Attribute zu verlagern.
>>> <table themengebiet="bla"/>...</table>
>>
>> Es geht nicht nur um "Annotationen".
>>
>> Es geht mir um gut lesbare, sprechende Elementnamen.
>> Möglichst selten mit Attributen.
>
> Zur Verwaltung wirst Du mit der Zeit einiges finden, was Du gerne in Attributen
> noch unterbringst, um dann z.B. alle INtervioews mit XY,
> oder alle zwischen zwei bestimmten Zeitpunkten zu finden und zu ordnen.
Grundsätzlich ACK.
Allerdings ist gerade der Interviewzeitpunkt eine Information, die ich
in ein Element setzen würde.
Denn es ist sehr wahrscheinlich, dass man diese Information dem Nutzer
zugänglich machen möchte.
>>> Du willst doch sowieso mit XSLT oder sonstwie die auszuliefernden
>>> Dokumente (und Uebersichtsseiten, Sammlungen, Verlinkungen etc)
>>> erzeugen. Dort muessen die Annotationen ja garnicht drin sein. Das
>>> kann reines XHTML sein.
>>
>> Eigentlich möchte ich genau das nicht pauschal tun - für jedes
>> Element.
>>
>> Nur wenn es wirklich starke Gründe dafür gibt.
>
> Die Elemente mit Deinen "sprechenden" Elementnamen musst Du
> transformieren.
Warum denkst Du, ist dies zwingend nötig?
Nochmal zur Klarstellung:
Der Browser kann semantisch weder mit
<div class="interview"><div>
noch mit
<interview></interview>
was anfangen.
[...]
>>> Deswegen sollte man an sich nicht die XHTML-DTD "erweitern", sondern
>>> seine eigenen Angelegenheiten in separaten Namespaces getrennt halten
>>> (Bezug zu oben (*)). Und dann XHTML generieren, wobei man die
>>> Annotationen verwendet um zu steuern was man generiert.
>>
>> Mein Ziel ist besser lesbarer und von technischen Metainformationen
>> weithin befreiter Quellcode.
>
> technische (im Sinn von optischem Markup) bekommst Du ganz raus, wenn
> Du sie ins XSLT-Stylesheet verlagerst.
ACK
> Die anderen (Interviewter,
> Datum, Kommentar) betrachte ich als semantische Metainformationen,
"Information in ein Attribut oder in ein Element?" scheint mir eine
der schwierigsten Entscheidungen zu sein, wenn man einen Inhalt
analysiert um dafür eine gute(tm) DTD zu entwickeln.
Das sollten wir hier vielleicht besser nicht ausbreiten, sondern
beizeiten in einem eigenen Thread.
Nur als kurze Entgegnung:
Informationen, die potentiell für eine Nutzergruppe (mit bestimmten
Clients) nützlich sein könnte, sollte aus ganz pragmatischen
Erwägungen wohl gleich von Anfang in ein Element.
/Ausblenden/ von Elementen ist einfach. (Ich benutze hier "Ausblenden"
in einem allgemeinen Sinn als Platzhalter. Es geht natürlich
keineswegs nur um sehenden Nutzer.)
/Einblenden/ von Attribut-Inhalten ist umständlich bis unmöglich.
> da
> ist es IMHO sinnvoll, sie im Dokument mit abzulegen um auch die
> Dokumente gemeinsam verwalten und ggf selektiert und geordnet
> bereitstellen zu koennen.
Andreas
--
http://borumat.de
Wolfgang May
> Wolfgang May schrieb:
> > Diese willst Du jetzt (i) lesbar (als XHTML) bereitstellen,
>
> An diesem wesentlichen Punkt muss ich einhaken.
>
> Ich möchte es, wenn es irgendwie machbar ist, eben nicht /prinzipiell/
> die "Andreas-Elemente" in XHTML-Elemente (per XSLT) transformieren
> (müssen).
>
> Falls das nötig wäre, verlöre die ganze Sache enorm an Attraktivität.
>
> Und nicht zuletzt geht es mir nur um die "Schönheit" des Markups des
> lokalen, sondern auch des ausgelieferten Dokumentes.
Ich habe den Eindruck, dass Du im Moment noch mit der Trennung
kaempfst zwischen Deinem internen Format mit allen Informationen, und
dem was Du (und ggf wozu) auslieferst. Bei Auslieferung an einen
Browser hast Du an sich wenig davon, Deine eigenen Elemente
auszuliefern - schlimmstenfalls kann der kein CSS und versteht Deine
Elemente nicht (und ranzt einfach allen Textinhalt als langen String
runter, wie es Browser bis vor einigen jahren mit XML-Dokumenten
taten).
Bei Auslieferung an sonst ein Tool, das etwas mit der Semantik Deiner
Elemente anfangen kann, kannst Du eine beliebige XML-Transformation
Deines internen Formats ausliefern, die der vereinbarten Austausch-DTD
genuegt (ggf auch in ganz andere Elementnamen, die der Empfaenger
wuenscht, transformieren).
Das "schoenste" sollte somit eigentlich Dein eigenes, internes Dokument
sein. Dann kannst Du alles andere daraus machen, und jedem das schicken,
was er will.
> Vielleicht noch ein Beispiel, wofür ich bewußt XSLT einsetzen möchte.
>
> Auszuliefernder Code:
>
> <a class="pic" title="Größere Version des Bildes anzeigen"
> href="bild-1.big.png"><img src="bild-1.png" alt="Lorem" /><img
> src="bild-1.png" alt="Lorem" /></a>
>
> Das Class-Attribut ist allein für olle Browser drin, die nicht
> vernünftig mit Attributselektoren umgehen können.
>
> Lokaler Code:
>
> <a href="bild-1.big.png"><img src="bild-1.png" alt="Lorem" /></a>
>
> Das Class-Attribut soll also per XSLT hinzugefügt werden.
> Es hat kein Existenzrecht im Quelldokument.
>
> Ein alternativer, noch besserer, lokaler Code wäre:
>
> <img src="bild-1.png" alt="Lorem" href="bild-1.big.png" />
Das ist mit XSLT kein Problem (sondern eine der typischen Aufgaben,
von denen die Entwicklung ausging): wenn es den Auftrag bekommt, ein
<image>-Element des gespeicherten Formats abzubilden (ich verwende
absichlich image, um zu zeigen, dass es sozusagen Dein eigener Tag
fuer ein Bild ist), kann es daraus beliebiges XML/XHTML erzeugen in
das es Infos aus Deinem <image>-Element einbaut:
Dein Code:
<image src="bild-1.png" alt="Lorem" href="bild-1.big.png" />
Template:
<xsl:template match="image">
<a class="pic" title="Größere Version des Bildes anzeigen"
href="{@href}"><img src="{@src}" alt="{@alt}"/></a>
</xsl:template>
Output:
<a class="pic" title="Größere Version des Bildes anzeigen"
href="bild-1.big.png">
<img src="bild-1.png" alt="Lorem" /></a>
> > siehe oben. Man kann in einem Dokument beide mischen.
> > Das Problem, was Du in einem spaeteren Posting noch andeutest, ist, dass Du
> > fuer Deine Tools nur eine DTD haben kannst.
>
> Dann habe ich mich missverständlich ausgedrückt.
> Es geht nicht darum, was mein Editor kann oder nicht.
>
> Es geht darum, dass man für ein Wurzelelement nicht einfach zwei DTDs
> angeben darf.
>
> Also:
> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
> "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
> <!DOCTYPE html SYSTEM "custom.dtd">
Schlussendlich dasselbe Problem. Nein, nicht mal:
eine DTD koennte eine weitere importieren, womit aber die Einbettung
der Elemente der einen in die andere noch nicht gemacht ist, bzw nur dort
wo ein ANY steht, passt.
Bleibt festzuhalten: beide Anteile muessen in eine kombinierte DTD.
ich nehme das jetzt mal von weiter unten hoch:
> "Information in ein Attribut oder in ein Element?" scheint mir eine
> der schwierigsten Entscheidungen zu sein, wenn man einen Inhalt
> analysiert um dafür eine gute(tm) DTD zu entwickeln.
> Das sollten wir hier vielleicht besser nicht ausbreiten, sondern
> beizeiten in einem eigenen Thread.
... und binde es trotzdem hier ein, weil das weitere auch davon
(zumindest von dem beispiel dazu) abhaengt:
An sich ist es egal.
Es gibt nur wenige Regeln: wenn man etwas moeglicherweise spaeter mal
feiner stukturieren oder annotieren will, oder wenn etwas keine ID und kein NMTOKEN
(= string ohne whitespace) ist, und mehfach vorkommen kann) dann soll man es in
ein Element packen:
* Entwurf
<person><name>Karl Napf</name></person>
spaetere Entscheidung:
<person><name><givenname>Karl</givenname>
<middleinitial>X</middleinitial>
<familyname>Napf</familyname></person>
* Entwurf
<city><population>100000</population></city>
spaetere Entscheidung:
<city><population year="2010">100000</population>
<population year="2012">102000</population></city>
* Entwurf
<interview>
<mit>Karl Napf</mit>
<frage>...</frage>
<antwort>...</>
Spaetere Entscheidung:
<interview>
<mit>Karl Napf</mit>
<mit>Anna Napf</mit>
<frage>...</frage>
<antwort von="Anna Napf">Ja. <em>Ich</em> habe das gesagt.</>
...
</>
Wenn man da Attribute gewaehlt haette, kaeme man in Teufels Kueche.
Wenn man DTDs und ID/IDREF verwendet, gibt es noch eine zweite
Regel: alles was ID oder IDREF muss ein Attribut sein
<country code="D" memberships="EU NATO ..."> ... </country>
<organization abbrev="EU" members="D F E B ...">...</>
... unten gehts dazu noch etwas weiter ...
> >>>> Zum Beispiel verbietet es sich im Hinblick auf Barrierearmut eigene
> >>>> Elemente für Überschriften zu verwenden.
> >>>
> >>> Das spraeche fuer die Wahl, alle Annotationen in Attribute zu verlagern.
> >>> <table themengebiet="bla"/>...</table>
> >>
> >> Es geht nicht nur um "Annotationen".
> >>
> >> Es geht mir um gut lesbare, sprechende Elementnamen.
> >> Möglichst selten mit Attributen.
> >
> > Zur Verwaltung wirst Du mit der Zeit einiges finden, was Du gerne in Attributen
> > noch unterbringst, um dann z.B. alle INtervioews mit XY,
> > oder alle zwischen zwei bestimmten Zeitpunkten zu finden und zu ordnen.
>
> Grundsätzlich ACK.
> Allerdings ist gerade der Interviewzeitpunkt eine Information, die ich
> in ein Element setzen würde.
> Denn es ist sehr wahrscheinlich, dass man diese Information dem Nutzer
> zugänglich machen möchte.
Eine uebliche Konvention ist, dass man bei dokumentenorientiertem XML
Struktur und Text ueber Elemente und Elementinhalte macht, und alle
Metainformationen und Annotationen in Attribute. Damit waere Datum
und Name des Antorters (wenn Karl und Anna Napf gefragt werden) in der
Speicherung zuerst mal ein Attribut. In der Aufbereitung als XHTML
(durch XSLT-Transformation) kann das ja anders sein und in den Text
abgebildet werden, z.B. obige Antwort von Anna Napf mit
<xsl:template match="antwort">
<b>Antwort</b>
(<xsl:value-of select="@von"/>)<b>:</b>
<xsl:apply-templates select="text()|*"/>
</xsl:template>
transformieren ergibt
<b>Antwort</b> (Anna Napf)<b>:Ja. <em>Ich</em> habe das gesagt.
Selbst wenn Du Dich beim ersten Design mal irgendwo mit
Attribut/Subelement vergreifst, und das spaeter noch aendern willst,
musst Du nur in den (wenigen) Stylesheets zur
Verarbeitung/Auslieferung dann lokale Aenderungen machen.
> >>> Du willst doch sowieso mit XSLT oder sonstwie die auszuliefernden
> >>> Dokumente (und Uebersichtsseiten, Sammlungen, Verlinkungen etc)
> >>> erzeugen. Dort muessen die Annotationen ja garnicht drin sein. Das
> >>> kann reines XHTML sein.
> >>
> >> Eigentlich möchte ich genau das nicht pauschal tun - für jedes
> >> Element.
> >>
> >> Nur wenn es wirklich starke Gründe dafür gibt.
> >
> > Die Elemente mit Deinen "sprechenden" Elementnamen musst Du
> > transformieren.
>
> Warum denkst Du, ist dies zwingend nötig?
>
> Nochmal zur Klarstellung:
> Der Browser kann semantisch weder mit
> <div class="interview"><div>
> noch mit
> <interview></interview>
> was anfangen.
Ja gut, soweit schon.
Trotzdem ist es noch ein Unterschied, dass <div> HTML ist, und er es hat falls er
mit class und CSS nicht zurechtkommt, waehrend er mit <interview> definitiv
nichts anfangen kann, und es ignorieren muss.
Ich wuerde nur reines XHTML+CSS ausliefern (siehe auch unterster Absatz,
oder Rueckfrage "warum willst Du einen "Zwitter" aus XHTML und reingemischten
eigenen Tags, die doch wieder etwas anders als im gespeicherten Dokument sind,
ausliefern?" - eine klare Trennung ist hier meistens ueblicher).
> > Die anderen (Interviewter,
> > Datum, Kommentar) betrachte ich als semantische Metainformationen,
>
> Nur als kurze Entgegnung:
> Informationen, die potentiell für eine Nutzergruppe (mit bestimmten
> Clients) nützlich sein könnte, sollte aus ganz pragmatischen
> Erwägungen wohl gleich von Anfang in ein Element.
> /Ausblenden/ von Elementen ist einfach. (Ich benutze hier "Ausblenden"
> in einem allgemeinen Sinn als Platzhalter. Es geht natürlich
> keineswegs nur um sehenden Nutzer.)
> /Einblenden/ von Attribut-Inhalten ist umständlich bis unmöglich.
In dem, was Du in XHTML (mit/ohne CSS) auslieferst kann das zutreffen
(dazu kenne ich mich jetzt mit CSS zuwenig aus, ob man damit
Attributwerte nicht auch einblenden kann).
Auf XSLT-Ebene kannst Du das aber beliebig machen, siehe obiges Beispiel
(und auch das interview-Beispiel von gestern mittag, wo ich genau das
mit @datum mache -> "Interview mit $person vom $datum".
Die Speicherung bzw DTD des "Original"-Dokumentes ist ja komplett
unabhaengig von der Struktur des ausgelieferten Dokumentes. Aus dem
Grund hat man normalerweise auch die "eigenen" "semantischen" Tags nur
im gespeicherten Dokument, und liefert XHTML (oder ein XML zu einer
mehr oder weniger anderen Ziel-DTD, die "zufaellig" dieselben Tags,
aber evtl mit anderer Struktur haben kann [das waere der Fall, wenn DU
irgendwann jemanden kennenlernst, der etwas ganz aehnliches macht,
aber sich eine etwas andere DTD dafuer entwickelt hatte]) aus.
Wolfgang
Andreas Borutta
>> Denkst du, dass man mit Python ebenfalls auf "gute Weise" auf den Baum
>> zugreifen kann um bestimmte Manipulationen - siehe mein bereits
>> gepostetes Beispiel zur Sitemap - vorzunehmen?
> Was heisst in diesem Zusammenhang "ungeeignet". Gehen wird es in jeder
> universellen Programmiersprache, sonst wäre sie wohl auch nicht universell.
Ob eine Programmiersprache sich konzeptionell gut für das Erledigen
der oben genannten Aufgabe eignet, können nur erfahrene
Programmierer/Informatiker sagen, die mehrere Sprachen gut kennen.
Ich kann es nicht.
Es geht explizit nicht darum ob es "irgendwie geht".
"Auf gute Weise" könnte ich so umschreiben:
Ein erfahrener Programmierer vergleicht die Listings für die obige
Aufgabe in mehrerer Programmiersprachen.
"Sprache ...: Whow, elegant. Schön. Übersichtlich. Klar. Passt von
ihren Intentionen, ihrem Wesen, ihrem Charakter hervorragend zur
Aufgabe."
Andreas
--
http://borumat.de
Andreas Borutta
Ich führe aus verschiedenen Postings Teile hier zusammen, straffe
etwas und setze einige Überschriften, damit ein guter Überblick
gewahrt bleibt.
Im Folgenden bezeichne ich eine vom Autor selbstverfasste DTD, die aus
einer ergänzten XHTML-DTD besteht als "XHTML-plus-FZ-DTD".
"FZ" steht für ein konkretes Web-Projekt: fahrradzukunft.de
Die vom Autor in dieser DTD zusätzlich deklarierten Elemente bezeichne
ich als "FZ-Elemente".
Kurze Ankündigung:
Ich kann mich erst wieder ab Sonntag wieder melden.
***
Ziel
***
Dokument enthält XHTML-Elemente und FZ-Elemente.
Namespaces in Elementen werden nicht verwendet.
<h1>...</h1>
<p>...</p>
<interview>
<frage>
<sprecher>...</sprecher>
...
</frage>
<antwort>
<sprecher>...</sprecher>
...
</antwort>
<frage>
<sprecher>...</sprecher>
...
</frage>
<antwort>
<sprecher>...</sprecher>
...
</antwort>
</interview>
<p>...</p>
***
FZ-Elemente vor dem Ausliefern per XSLT in XHTML-Elemente umwandeln?
***
>> Ich möchte es, wenn es irgendwie machbar ist, eben nicht /prinzipiell/
>> die "Andreas-Elemente" in XHTML-Elemente (per XSLT) transformieren
^^^^^^^^^^^^^^^^
Ab jetzt FZ-Elemente.
>> (müssen).
>>
>> Falls das nötig wäre, verlöre die ganze Sache enorm an Attraktivität.
>>
>> Und nicht zuletzt geht es mir nur um die "Schönheit" des Markups des
>> lokalen, sondern auch des ausgelieferten Dokumentes.
>> Der Browser kann semantisch weder mit
>> <div class="interview"><div>
>> noch mit
>> <interview></interview>
>> was anfangen.
> Ja gut, soweit schon.
> Trotzdem ist es noch ein Unterschied, dass <div> HTML ist, und er es hat falls er
> mit class und CSS nicht zurechtkommt, waehrend er mit <interview> definitiv
> nichts anfangen kann, und es ignorieren muss.
Ein berechtigter Einwand.
Auf meiner ToDo steht noch "Wie gehen Screenreader mit FZ-Elementen
um"?
Bevor das geklärt werden kann, muss jedoch zunächst festgestellt
werden, ob es überhaupt eine praxistaugliche Art für normale visuelle
Browser gibt, ein Dokument mit XHTML-plus-DTD auszuliefern.
Geprüft habe ich schon, wie visuelle Browser ein XML-Dokument ohne CSS
darstellen:
Genau wie Du weiter unten schriebst, als langen String.
Aber damit könnte man leben, denke ich.
Schön ist es nicht.
"Alle Elemente ohne Gestalthinweise als Blockelement darstellen", wäre
ein angenehmerer Default.
> Ich habe den Eindruck, dass Du im Moment noch mit der Trennung
> kaempfst zwischen Deinem internen Format mit allen Informationen, und
> dem was Du (und ggf wozu) auslieferst.
So kann man es sehen, ACK.
> Das "schoenste" sollte somit eigentlich Dein eigenes, internes Dokument
> sein. Dann kannst Du alles andere daraus machen, und jedem das schicken,
> was er will.
Klar, das kann man tun. Das steht jedoch nicht im Widerspruch zu
meinem Wunsch, nur in besonderen Fällen die FZ-Elemente per XSLT in
XHTML-Elemente umwandeln zu lassen.
Ich möchte ganz schlicht so wenig Umformungsaufwand wie irgend möglich
betreiben. Bei der Prämisse: Verwendung von FZ-Elementen.
Du fragtest "warum ich einen Zwitter wolle".
Das Bild empfinde ich nicht als passend.
Ich sehe es als "Anreicherung".
Und ich möchte, so keine starken Argumente, die z.B. die
Zugänglichkeit betreffen, auch beim Ausliefern, so wenig wie möglich
von dieser Anreicherung "vernichten" (durch Umwandlung).
***
FZ-Elemente, die auf jeden Fall per XSLT in XHTML-Elemente
umgewandelt werden sollen
***
>> Vielleicht noch ein Beispiel, wofür ich bewußt XSLT einsetzen möchte.
>>
>> Auszuliefernder Code:
>>
>> <a class="pic" title="Größere Version des Bildes anzeigen"
>> href="bild-1.big.png"><img src="bild-1.png" alt="Lorem" /><img
>> src="bild-1.png" alt="Lorem" /></a>
>>
>> Das Class-Attribut ist allein für olle Browser drin, die nicht
>> vernünftig mit Attributselektoren umgehen können.
>>
>> Lokaler Code:
>>
>> <a href="bild-1.big.png"><img src="bild-1.png" alt="Lorem" /></a>
>>
>> Das Class-Attribut soll also per XSLT hinzugefügt werden.
>> Es hat kein Existenzrecht im Quelldokument.
>>
>> Ein alternativer, noch besserer, lokaler Code wäre:
>>
>> <img src="bild-1.png" alt="Lorem" href="bild-1.big.png" />
>
> Das ist mit XSLT kein Problem
Klar.
Ich wollte mit der Nennung des Beispiels nur deutlich machen, in
welchen Fällen ich umwandeln /will/.
Danke dennoch für Deinen XSLT-Code.
***
Angabe der XHTML-plus-FZ-DTD im Dokumentkopf
***
> * Wenn du in dem Ausgangsdokument o.g. W3C-DTD im Header listest,
> wird es Dich beim Aufruf eines XSLT-Tools (komplett unerwartet)
> auf die Schn**ze hauen (wie mich vor ein paar Wochen, der Thread muesste
> noch zugreifbar sein ...). [...]
Mist. Das könnte der Todesstoß für meine Idee sein.
Denn ich will definitiv nicht noch zig "Schichten" verwenden um solche
Probleme zu umschiffen.
> Hier siehts so aus:
>
> ### file index.xml
> <?xml version="1.0" encoding="ISO-8859-1"?>
> <?xml-stylesheet type="text/xsl" href="Stylesheets/dbis-general.xsl"?>
> <!DOCTYPE html
> PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
> "http://www.dbis.informatik.uni-goettingen.de/DTDs/xhtml1-strict.dtd">
> usw...
> ######
Ich muss mich noch belesen, welche Nachteile es hat, normale
XHTML-Dokumente (also ganz ohne XTHML-plus-FZ-DTD) als XML
auszuliefern.
Da gab es AFAIR welche.
Jedenfalls gibt es längliche Kontroversen unter Experten zur "besten
Art" ein XHTML-Dokument auszuliefern.
***
Buchempfehlung zu XSLT
***
> schau Dir mal "XSLT Programmers Reference" von Michael Kay an.
Danke.
***
Information in ein Attribut oder in ein Element
***
>> "Information in ein Attribut oder in ein Element?" scheint mir eine
>> der schwierigsten Entscheidungen zu sein, wenn man einen Inhalt
>> analysiert um dafür eine gute(tm) DTD zu entwickeln.
>> Das sollten wir hier vielleicht besser nicht ausbreiten, sondern
>> beizeiten in einem eigenen Thread.
>
> ... und binde es trotzdem hier ein, weil das weitere auch davon
> (zumindest von dem beispiel dazu) abhaengt:
>
> An sich ist es egal.
> Es gibt nur wenige Regeln: wenn man etwas moeglicherweise spaeter mal
> feiner stukturieren oder annotieren will,
Genau das ist doch bei einer /Entwicklung/ einer DTD der Standardfall.
Das ist doch ein evolutionärer Prozess.
[Beispiele]
Die Nachteile anders ausgedrückt:
* ein Attribut darf pro Element nur ein einziges Mal vorkommen
* jedes Attribut darf nur einen Wert enthalten
(Apropos: Offenbar bricht XHTML mit dieser Regel, denn
| class="foo bar"
ist erlaubt. Aber das nur am Rande.)
* es kann keine feste Reihenfolge Attribute vorgegeben werden
> Wenn man da Attribute gewaehlt haette, kaeme man in Teufels Kueche.
Eben.
Weitere Nachteile von Attributen sehe ich:
Sie lassen sich nicht verschachteln, sie dürfen keine Struktur
aufweisen.
Lautet also das Fazit:
Attribute vermeiden und einzig für IDs verwenden.
Da fragt man sich, ob es besser wäre, wenn XML gänzlich auf Attribute
verzichtet hätte. Denn eine ID lässt sich schließlich auch per
Unterelement angeben.
>>> Zur Verwaltung wirst Du mit der Zeit einiges finden, was Du gerne in Attributen
>>> noch unterbringst, um dann z.B. alle INtervioews mit XY,
>>> oder alle zwischen zwei bestimmten Zeitpunkten zu finden und zu ordnen.
>>
>> Grundsätzlich ACK.
>> Allerdings ist gerade der Interviewzeitpunkt eine Information, die ich
>> in ein Element setzen würde.
>> Denn es ist sehr wahrscheinlich, dass man diese Information dem Nutzer
>> zugänglich machen möchte.
>
> Eine uebliche Konvention ist, dass man bei dokumentenorientiertem XML
> Struktur und Text ueber Elemente und Elementinhalte macht, und alle
> Metainformationen und Annotationen in Attribute.
Ich denke es dürfte schwer bis unmöglich sein ein belastbare
Definition zur Abgrenzung von "Text", "Metainformation" und
"Annotation" zu finden.
>> Informationen, die potentiell für eine Nutzergruppe (mit bestimmten
>> Clients) nützlich sein könnte, sollte aus ganz pragmatischen
>> Erwägungen wohl gleich von Anfang in ein Element.
>> /Ausblenden/ von Elementen ist einfach. (Ich benutze hier "Ausblenden"
>> in einem allgemeinen Sinn als Platzhalter. Es geht natürlich
>> keineswegs nur um sehenden Nutzer.)
>> /Einblenden/ von Attribut-Inhalten ist umständlich bis unmöglich.
>
> In dem, was Du in XHTML (mit/ohne CSS) auslieferst kann das zutreffen
> (dazu kenne ich mich jetzt mit CSS zuwenig aus, ob man damit
> Attributwerte nicht auch einblenden kann).
Kann man.
Aber die Möglichkeiten damit sind sehr eingeschränkt.
Die Browserunterstützung auch.
> Auf XSLT-Ebene kannst Du das aber beliebig machen, siehe obiges Beispiel
> (und auch das interview-Beispiel von gestern mittag, wo ich genau das
> mit @datum mache -> "Interview mit $person vom $datum".
Es ist gut, von diesen Möglichkeiten zu wissen.
Andreas
--
http://borumat.de
Daniel Urban
> Wolfgang May schrieb:
[...]
> Attribute vermeiden und einzig für IDs verwenden.
>
> Da fragt man sich, ob es besser wäre, wenn XML gänzlich auf Attribute
> verzichtet hätte. Denn eine ID lässt sich schließlich auch per
> Unterelement angeben.
Wie Wolfgang schrieb, ist die Attributierung/Annotation für Metadaten zu
verwenden. Es ist also eine zweite Ebene. Die ID ist ein klares Metadatum
und hat nichts in den Daten eines solchen Dokuments zu suchen. Ich gebe
allerdings zu, dass die Unterscheidung zwischen Daten und Metadaten bei
manchen Dokumenten etwas durcheinander geht. Wenn man XHTML als Struktur von
Inhalten ohne Layout betrachtet würde, dann müssten Tags wie b, i, em usw.
als Attribute existieren. Wenn man aber XHTML als Struktur von Layout und
Inhalt betrachtet, dann sind genannte Element keine Metadaten. Die ID bleibt
aber auch in diesem Fall ein Metadatum, da es weder Inhalt noch Layout ist.
[...]
>> Eine uebliche Konvention ist, dass man bei dokumentenorientiertem XML
>> Struktur und Text ueber Elemente und Elementinhalte macht, und alle
>> Metainformationen und Annotationen in Attribute.
>
> Ich denke es dürfte schwer bis unmöglich sein ein belastbare
> Definition zur Abgrenzung von "Text", "Metainformation" und
> "Annotation" zu finden.
Ich glaube, dass Du irrst. In der Regel kann man ganz gut zwischen
Metdadaten und Daten unterscheiden.
Gruß,
Daniel
Wolfgang May
> etwas und setze einige �berschriften, damit ein guter �berblick
> gewahrt bleibt.
>
> Im Folgenden bezeichne ich eine vom Autor selbstverfasste DTD, die aus
> "FZ" steht f�r ein konkretes Web-Projekt: fahrradzukunft.de
>
> Die vom Autor in dieser DTD zus�tzlich deklarierten Elemente bezeichne
> ich als "FZ-Elemente".
>
> Kurze Ank�ndigung:
> Ich kann mich erst wieder ab Sonntag wieder melden.
>
>
> ***
> Ziel
> ***
>
> Namespaces in Elementen werden nicht verwendet.
>
> <h1>...</h1>
> <p>...</p>
> <interview>
> <frage>
> <sprecher>...</sprecher>
> ...
> </frage>
> <antwort>
> <sprecher>...</sprecher>
> ...
> </antwort>
> <frage>
> <sprecher>...</sprecher>
Hier wuerde man nach der ueblichen Unterscheidung in Daten/Metadaten
(s.u.) Sprecher eher als Attribut machen, geht aber auch so.
> </interview>
> <p>...</p>
>
> ***
> FZ-Elemente vor dem Ausliefern per XSLT in XHTML-Elemente umwandeln?
> ***
>
> >> Ich m�chte es, wenn es irgendwie machbar ist, eben nicht /prinzipiell/
> >> die "Andreas-Elemente" in XHTML-Elemente (per XSLT) transformieren
> ^^^^^^^^^^^^^^^^
> Ab jetzt FZ-Elemente.
> >> (m�ssen).
> >>
> >> Falls das n�tig w�re, verl�re die ganze Sache enorm an Attraktivit�t.
> >>
> >> Und nicht zuletzt geht es mir nur um die "Sch�nheit" des Markups des
> >> lokalen, sondern auch des ausgelieferten Dokumentes.
>
> >> Der Browser kann semantisch weder mit
> >> <div class="interview"><div>
> >> noch mit
> >> <interview></interview>
> >> was anfangen.
>
> > Ja gut, soweit schon.
> > Trotzdem ist es noch ein Unterschied, dass <div> HTML ist, und er es hat falls er
> > mit class und CSS nicht zurechtkommt, waehrend er mit <interview> definitiv
> > nichts anfangen kann, und es ignorieren muss.
>
> Ein berechtigter Einwand.
> Auf meiner ToDo steht noch "Wie gehen Screenreader mit FZ-Elementen
> um"?
> Bevor das gekl�rt werden kann, muss jedoch zun�chst festgestellt
> werden, ob es �berhaupt eine praxistaugliche Art f�r normale visuelle
> Browser gibt, ein Dokument mit XHTML-plus-DTD auszuliefern.
>
> Gepr�ft habe ich schon, wie visuelle Browser ein XML-Dokument ohne CSS
> darstellen:
> Genau wie Du weiter unten schriebst, als langen String.
> Aber damit k�nnte man leben, denke ich.
> Sch�n ist es nicht.
An sich war das das Standardverhalten von vor 5 (oder mehr) Jahren.
> "Alle Elemente ohne Gestalthinweise als Blockelement darstellen", w�re
> ein angenehmerer Default.
Die meisten Browser machen immerhin, wenn sie ein wohlgeformtes
XML-Dokument finden, mit dem sie nicht viel anfangen koennen,
eine Schachtelstruktur auf, wo man die Elemente auf- und zuklicken
("expandieren") kann (so wie viele XML-Editoren).
Ist aber an sich fuer Deine Zwecke auch egal (fuer die Lehre ist es
ganz schoen, dass man jedes XML-Dokument auch mal schnell im Browser
aufmachen kann).
> > Ich habe den Eindruck, dass Du im Moment noch mit der Trennung
> > kaempfst zwischen Deinem internen Format mit allen Informationen, und
> > dem was Du (und ggf wozu) auslieferst.
>
> So kann man es sehen, ACK.
>
> > Das "schoenste" sollte somit eigentlich Dein eigenes, internes Dokument
> > sein. Dann kannst Du alles andere daraus machen, und jedem das schicken,
> > was er will.
>
> Klar, das kann man tun. Das steht jedoch nicht im Widerspruch zu
> meinem Wunsch, nur in besonderen F�llen die FZ-Elemente per XSLT in
> XHTML-Elemente umwandeln zu lassen.
>
> Ich m�chte ganz schlicht so wenig Umformungsaufwand wie irgend m�glich
> betreiben. Bei der Pr�misse: Verwendung von FZ-Elementen.
Dein Begriff von Umformungsaufwand ist intuitiv begruendet, aber in
Wirklichkeit nicht da (wenn Du XSLT verwendest; wenn Du mit Updates
tatsaechlich den Baum veraendern wuerdest (und das Ausgangsdokument
dabei zerstoeren wuerdest) waere er da):
Codierungsaufwand:
ob Du einmal die CSS-Darstellungsdefinition entwickelst, oder
einmal ein XSLT-Template, ist egal.
Ausfuehrungsaufwand:
ob der Prozessor einmal rekursiv Dein Element unveraendert
kopiert (ueblicherweise erzeugt er eine neue Kopie), oder
eine einfache Transformation ausfuehrt, ist fast auch egal.
Darstellungsaufwand fuer den Browser:
auch egal. Evtl einfacher wenn erst nach XHTML transformiert
wurde, und damit das CSS etwas einfacher ist.
> Du fragtest "warum ich einen Zwitter wolle".
> Das Bild empfinde ich nicht als passend.
>
> Ich sehe es als "Anreicherung".
> Und ich m�chte, so keine starken Argumente, die z.B. die
> Zug�nglichkeit betreffen, auch beim Ausliefern, so wenig wie m�glich
> von dieser Anreicherung "vernichten" (durch Umwandlung).
Wer hat nachher was von dem angereicherten Dokument? Wenns sowieso
an den Browser geht, ist es egal.
Wenn jemand noch damit arbeiten soll, waere es besser ihm gleich
das Ausgangsdokument mit allem zu schicken.
> ***
> Angabe der XHTML-plus-FZ-DTD im Dokumentkopf
> ***
>
> > * Wenn du in dem Ausgangsdokument o.g. W3C-DTD im Header listest,
> > wird es Dich beim Aufruf eines XSLT-Tools (komplett unerwartet)
> > auf die Schn**ze hauen (wie mich vor ein paar Wochen, der Thread muesste
> > noch zugreifbar sein ...). [...]
>
> Mist. Das k�nnte der Todessto� f�r meine Idee sein.
> Denn ich will definitiv nicht noch zig "Schichten" verwenden um solche
> Probleme zu umschiffen.
Mmentan denke ich, dass es Dich nicht betrifft:
Wenn Du eh eine erweiterte DTD haben willst, liegt Die sowieso bei Dir.
Das bisschen Umlaute-Entities etc vom W3C zu kopieren oder den catalog
einzurichten macht den Kohl nicht fett.
Mir fallen da direkt erstmal nur die Umlaut-Entities ä usw
ein.
Im Ergebnisdokument kannst Du (nach meinen Erfahrungen) die W3D-DTD im
Header angeben (daraus dass das geht, schlieese ich wiederum, dass
zumindest die von mir verwendeten XSLT-Prozessoren das erzeugte
XHTML-Dokument nicht validieren).
[...]
> Ich muss mich noch belesen, welche Nachteile es hat, normale
> XHTML-Dokumente (also ganz ohne XTHML-plus-FZ-DTD) als XML
> auszuliefern.
Ich glaube, keine (wirklichen) fuer den Browser (der weiss, dass er
HTML/XHTML erwartet und ist insgesamt sehr (fehler)tolerant - in der
Realitaet fliegt ja auch viel kaputtes HTML ohne Header rum).
> Da gab es AFAIR welche.
Fuer andere Anwendungen hat es (zumindest in der Theorie) den Nachteil,
dass die Anwendung (theoretisch) nicht weiss, dass es XHTML ist. In
der Praxis kann sie es sogar wissen, wenn Du den namespace verwendest.
Wenn nicht, weiss sie nur, dass aussenrum ein <html>-Element ist,
was (theoretisch) aus einer ganz anderen Sprache sein kann.
Ohne DTD fehlen ggf Infos, welche Attribute ID/IDREF sind.
Ein Grund mehr, an Nicht-Browser-Anwendungen das Originaldokument
mit Deiner XHTML+FZ-DTD auszuliefern.
> Jedenfalls gibt es l�ngliche Kontroversen unter Experten zur "besten
> Art" ein XHTML-Dokument auszuliefern.
Ja, "Best Practice ...", "How to Publish ..." usw.
Muss man IMHO manchmal etwas pragmatisch sehen.
> ***
> Information in ein Attribut oder in ein Element
> ***
>
> >> "Information in ein Attribut oder in ein Element?" scheint mir eine
> >> der schwierigsten Entscheidungen zu sein, wenn man einen Inhalt
> >> analysiert um daf�r eine gute(tm) DTD zu entwickeln.
> >> Das sollten wir hier vielleicht besser nicht ausbreiten, sondern
> >> beizeiten in einem eigenen Thread.
> >
> > ... und binde es trotzdem hier ein, weil das weitere auch davon
> > (zumindest von dem beispiel dazu) abhaengt:
> >
> > An sich ist es egal.
> > Es gibt nur wenige Regeln: wenn man etwas moeglicherweise spaeter mal
> > feiner stukturieren oder annotieren will,
>
> Genau das ist doch bei einer /Entwicklung/ einer DTD der Standardfall.
> Das ist doch ein evolution�rer Prozess.
>
> [Beispiele]
>
> Die Nachteile anders ausgedr�ckt:
>
> * ein Attribut darf pro Element nur ein einziges Mal vorkommen
> * jedes Attribut darf nur einen Wert enthalten
> (Apropos: Offenbar bricht XHTML mit dieser Regel, denn
> | class="foo bar"
> ist erlaubt. Aber das nur am Rande.)
ein. Die DTD bietet ja einige Attributtypen an:
CDATA: beliebig, darf leerzeichen enthalten
Das ganze Attribut ist dann ein Wert.
ID,IDREF,NMTOKEN: nur eine Zeichenkette ohne Leerzeichen
IDREFS (siehe vorangegangenes Posting mit
<organization abbrev="EU" members="D F NL ...">...</>
ist als mehrere Werte (zum Dereferenzieren) intendiert.
Bei Dereferenzierung in XPath
id(//organization[@abbrev="EU"]/@members)
wird es implizit gesplittet und einzeln dereferenziert
(und ergibt die Elemente
<country code="D">...</>, <country code="F">...</>, ...)
Aehnlich ist:
NMTOKENS: etwa Dein <div class="foo bar gaga">...</>, wo Werte
(die keine Leerzeichen enthalten duerfen) durch Leerzeichen
getrennt "gemeint" (s.u.) sind.
Der Wert des Attributs ist in dem Fall
string(//div/@class) = "foo bar gaga".
Allerdings bietet XPath kein eigenes Konstrukt um die
einzelnen gemeinten Werte zu gewinnen.
Das geht nur wenn man z.B. mit Java oder den string-Funktionen
von XPath/XQuery (die auch in XSLT dabei sind) explizit
herumnudelt. Also etwas lower-level als XML.
Das geht aber bei
<interview mit="Karl Napf Anna Napf"> schief, weil "Karl Napf"
kein NMTOKEN ist, und somit unklar ist, was ein Leerzeichen
bedeuten soll.
Das hat auch seinen Ursprung im SGML-Bereich, um Mengen
atomarer Datentypen noch gerade so fuer Attribute (und damit Metadaten)
zuzulassen.
> * es kann keine feste Reihenfolge Attribute vorgegeben werden
>
> > Wenn man da Attribute gewaehlt haette, kaeme man in Teufels Kueche.
>
> Eben.
>
> Weitere Nachteile von Attributen sehe ich:
>
> Sie lassen sich nicht verschachteln, sie d�rfen keine Struktur
> aufweisen.
Genau. Das ist der wesentliche Punkt, wann man ein Subelement und kein
Attribut verwenden muss.
> Lautet also das Fazit:
> Attribute vermeiden und einzig f�r IDs verwenden.
Kann man prinzipiell beim Entwurf einer eigenen DTD machen. Attribute
sind (auch im XML-Editor meistens) kleiner, man hat damit schon einen
gewissen Komfort- und Ueberblicks-Vorteil
> Da fragt man sich, ob es besser w�re, wenn XML g�nzlich auf Attribute
> verzichtet h�tte. Denn eine ID l�sst sich schlie�lich auch per
> Unterelement angeben.
Sie sind in der Dokumentwelt fuer die Metadaten ueblich. SGML (+seine DTDs)
war ja einer der Vorgaenger von XML.
Bei der Entwicklung von XML waren Vertreter der Dokumentwelt und der
Datenbankwelt massgeblich beteiligt, und mussten etwas finden, was
beides einigermassen abdeckt. Das spiegelt sich auch darin wieder
(womit dieser thread irgendwie mal anfing), dass DTD nicht mal
Datentypen wie zeichenkette/Zahl/Datum unterscheidet, sondern nur
PCDATA und CDATA (-> Daten, mit denen die Anwendung erst was anfangen
kann/muss) kennt. Das fuehrte dann zum XML Schema (insbesondere den
Simple Types, die Zahlentypen, Datum, Zeit etc umfassen, und damit
gegenueber der DTD echt hoehere Ausdruckskraft bieten). Die XML Schema
Complex Types sind dann Tribut an das was in DTD eigentlich besser
geht.
Es gab (1997-2001) auch Vorschlaege, DTD mit Simple Types zu ergaenzen
(was IMHO sehr sinnvoll gewesen waere).
Kommentar an dieser Stelle:
falls Du Datumswerte und Zeit verwenden willst, schau Dir die Syntaxvorgaben
fuer solche Werte in XML an:
http://www.w3.org/TR/xmlschema-2/#date
Etwas umstaendlich, aber dann bist Du damit konform zum Rest der Welt
und kannst mit diesen auch arbeiten (nach Datum ordnen, Zeitraeume "nix was
aelter ist als drei Jahre" etc testen).
> >>> Zur Verwaltung wirst Du mit der Zeit einiges finden, was Du gerne in Attributen
> >>> noch unterbringst, um dann z.B. alle INtervioews mit XY,
> >>> oder alle zwischen zwei bestimmten Zeitpunkten zu finden und zu ordnen.
> >>
> >> Grunds�tzlich ACK.
> >> Allerdings ist gerade der Interviewzeitpunkt eine Information, die ich
> >> in ein Element setzen w�rde.
> >> Denn es ist sehr wahrscheinlich, dass man diese Information dem Nutzer
> >> zug�nglich machen m�chte.
> >
> > Eine uebliche Konvention ist, dass man bei dokumentenorientiertem XML
> > Struktur und Text ueber Elemente und Elementinhalte macht, und alle
> > Metainformationen und Annotationen in Attribute.
>
> Ich denke es d�rfte schwer bis unm�glich sein ein belastbare
> Definition zur Abgrenzung von "Text", "Metainformation" und
> "Annotation" zu finden.
Jein.
Was Du meinst, ist dass Du bestimmte Dinge, die eigentlich Metadaten
zum Text sind (Datum des Interviews) in der Auslieferung zum
Text hinzunehmen willst. Da spricht nichts dagegen, aber damit wechseln
die Metadaten sozusagen die Seite:
Bei
<interview mit="Karl Napf" datum="1.1.2011">
<Frage> Herr Napf, wie sehen sie das?</Frage> ... </>
ist die Info, dass das Interview mit Karl Napf ist und am 1.1.2011
gemacht wurde, Metadaten. Wenn Du das als
<h2>Interview mit <font color="red">Karl Napf</font> am 1.1.2011</h2>
auslieferst, ist der Text "Interview mit Karl Napf am 1.1.2011"
die Daten, und die Tatsache, dass Karl Napf in rot gesetzt wird,
Metadaten. Der Effekt ist, dass ein dummer Browser immerhin noch
"Interview mit Karl Napf am 1.1.2011" ausgibt, und nicht
"Interview mit red Karl Napf am 1.1.2011".
Das bezieht sich aber im wesentlichen auf dokumentorientiertes XML als
Dokument gesehen. Wie das Beispiel Karl-Napf-Anna-Napf zeigt, ist es
manchmal aber notwendig, auch die Metadaten strukturiert als Baum
abzulegen. Einen Tod muss man sterben ;)
Ist also vieles auch Geschmackssache.
Wolfgang
Andreas Borutta
[...]
>>> Ich habe den Eindruck, dass Du im Moment noch mit der Trennung
>>> kaempfst zwischen Deinem internen Format mit allen Informationen, und
>>> dem was Du (und ggf wozu) auslieferst.
>>
>> So kann man es sehen, ACK.
>>
>>> Das "schoenste" sollte somit eigentlich Dein eigenes, internes Dokument
>>> sein. Dann kannst Du alles andere daraus machen, und jedem das schicken,
>>> was er will.
>>
>> Klar, das kann man tun. Das steht jedoch nicht im Widerspruch zu
>> meinem Wunsch, nur in besonderen F�llen die FZ-Elemente per XSLT in
>> XHTML-Elemente umwandeln zu lassen.
>>
>> Ich m�chte ganz schlicht so wenig Umformungsaufwand wie irgend m�glich
>> betreiben. Bei der Pr�misse: Verwendung von FZ-Elementen.
>
> Dein Begriff von Umformungsaufwand ist intuitiv begruendet, aber in
> Wirklichkeit nicht da (wenn Du XSLT verwendest; wenn Du mit Updates
> tatsaechlich den Baum veraendern wuerdest (und das Ausgangsdokument
> dabei zerstoeren wuerdest) waere er da):
>
> Codierungsaufwand:
> ob Du einmal die CSS-Darstellungsdefinition entwickelst, oder
> einmal ein XSLT-Template, ist egal.
Da stimme ich nicht zu.
Eine CSS-Regel f�r (um beim Beispiel zu bleiben) das Element, welches
den Interview-Inhalt enth�lt, muss eh formuliert werden.
Eine XSLT-Regel, die "<interview></interview>" umformt zu "<div
class="interview"></div>" k�me dazu.
> Ausfuehrungsaufwand:
> ob der Prozessor einmal rekursiv Dein Element unveraendert
> kopiert (ueblicherweise erzeugt er eine neue Kopie), oder
> eine einfache Transformation ausfuehrt, ist fast auch egal.
>
> Darstellungsaufwand fuer den Browser:
> auch egal. Evtl einfacher wenn erst nach XHTML transformiert
> wurde, und damit das CSS etwas einfacher ist.
Das ist "Aufwand f�r Maschinen". Den habe ich bei meinem Argument
nicht betrachtet.
>> Du fragtest "warum ich einen Zwitter wolle".
>> Das Bild empfinde ich nicht als passend.
>>
>> Ich sehe es als "Anreicherung".
>> Und ich m�chte, so keine starken Argumente, die z.B. die
^
vorliegen
>> Zug�nglichkeit betreffen, auch beim Ausliefern, so wenig wie m�glich
>> von dieser Anreicherung "vernichten" (durch Umwandlung).
>
> Wer hat nachher was von dem angereicherten Dokument? Wenns sowieso
> an den Browser geht, ist es egal.
Vorrangig geht es mir um eine grunds�tzliche Leitlinie:
"Konstruiere ein System nur gerade so komplex wie n�tig."
Eine System mit einer XSLT-Umformung ist komplexer als eines ohne eine
solche Umformung.
> Wenn jemand noch damit arbeiten soll, waere es besser ihm gleich
> das Ausgangsdokument mit allem zu schicken.
Das w�re ein weiteres Argument.
Wenn ich "<interview></interview>" statt "<div
class="interview"></div>" ausliefere, muss niemand umst�ndlich "nach
dem Ausgangsdokument fragen".
Anders:
Die "hochwertige" Form des Dokumentes ist die ausgelieferte,
�ffentlich verf�gbare Version.
Das gef�llt mir.
>> ***
>> Angabe der XHTML-plus-FZ-DTD im Dokumentkopf
>> ***
Mir ist noch nicht klar, wie man eine "angereicherte Kopie der
W3C-DTD" praxistauglich angibt.
So
http://borumat.de/xml-test/xhtml1-strict-plus-fz/
| <?xml version="1.0"?>
| <?xml-stylesheet type="text/css" href="default.css" ?>
| <!DOCTYPE html SYSTEM "default.dtd">
| <html>
| <head>
| <title>Foo</title>
| </head>
| <body>
| <h1>Foo</h1>
| <interview>Interview</interview>
| </body>
| </html>
geht es jedenfalls nicht.
FF stellt so "title" nicht wie erw�nscht dar.
Und es wird auch kein Useragent-Stylesheet angewendet.
Ich verstehe nicht alles des von Dir hier Geschriebenem:
Aber mir erscheint es ein "Improvisieren" zu sein, wenn Leerzeichen
als Trennzeichen f�r Werte verwendet werden.
Dass XPath nicht "von Hause" aus auf die einzelnen Werte zugreifen
kann, werte ich als Indiz daf�r, dass es sich um ein "Improvisieren"
handelt.
Danke f�r diesen kleinen Einblick zur Herkunft und zu Eigenheiten von
DTD.
[...]
>>> Eine uebliche Konvention ist, dass man bei dokumentenorientiertem XML
>>> Struktur und Text ueber Elemente und Elementinhalte macht, und alle
>>> Metainformationen und Annotationen in Attribute.
>>
>> Ich denke es d�rfte schwer bis unm�glich sein ein belastbare
>> Definition zur Abgrenzung von "Text", "Metainformation" und
>> "Annotation" zu finden.
>
> Jein.
> Was Du meinst, ist dass Du bestimmte Dinge, die eigentlich Metadaten
> zum Text sind (Datum des Interviews) in der Auslieferung zum
> Text hinzunehmen willst. Da spricht nichts dagegen, aber damit wechseln
> die Metadaten sozusagen die Seite:
> Bei
> <interview mit="Karl Napf" datum="1.1.2011">
> <Frage> Herr Napf, wie sehen sie das?</Frage> ... </>
> ist die Info, dass das Interview mit Karl Napf ist und am 1.1.2011
> gemacht wurde, Metadaten. Wenn Du das als
> <h2>Interview mit <font color="red">Karl Napf</font> am 1.1.2011</h2>
> auslieferst, ist der Text "Interview mit Karl Napf am 1.1.2011"
> die Daten, und die Tatsache, dass Karl Napf in rot gesetzt wird,
> Metadaten. Der Effekt ist, dass ein dummer Browser immerhin noch
> "Interview mit Karl Napf am 1.1.2011" ausgibt, und nicht
> "Interview mit red Karl Napf am 1.1.2011".
Ein wesentliches Ziel von gutem Markup ist Langlebigkeit.
Es soll f�r vielf�ltigste Zwecke verwendbar sein, ohne dass man es
erneut "anfassen" muss.
Attribute erf�llen das Merkmal nicht.
Sie engen erstens ein, weil sie bestimmte Formen der Darstellung
verhindern.
Sie engen zweitens ein, wenn das Dokument erg�nzt wird. Mit weiteren
Inhalten. Mit Inhalten, die pl�tzlich eine Substruktur erfordern.
Dann m�sste man das Attribut "wegwerfen" und "in einem Element
umwandeln".
Unsch�n. Verlust von Flexibilit�t.
Erst wenn eine "Transformations-Maschine" das Markup manipuliert, kann
man bestimmte Darstellungsziele bzw. die Substruktur erreichen.
Und genau diesen Zwang zur Verwendung einer "Transformations-Maschine"
m�chte ich ja, wie weiter oben erw�hnt, gerade nicht.
> Das bezieht sich aber im wesentlichen auf dokumentorientiertes XML als
> Dokument gesehen. Wie das Beispiel Karl-Napf-Anna-Napf zeigt, ist es
> manchmal aber notwendig, auch die Metadaten strukturiert als Baum
> abzulegen. Einen Tod muss man sterben ;)
> Ist also vieles auch Geschmackssache.
Hhmm.
Ich gestehe, dass ich da noch nicht �berzeugt bin.
Noch kenne ich keine glasklare scharfe Definition f�r "Bei diesem
Inhalt handelt es sich um Metadaten" und "Bei diesem Inhalt handelt es
sich um Daten".
Dabei soll sich die Entscheidung an der Semantik festmachen und nicht
an sp�teren, m�glichen Ausgabevarianten.
Andreas
P.S.: Ich kann mich erst nach den Feiertagen wieder melden
Wolfgang May
aus (mindestens) drei Aspekten sehen:
* XML zur Datenspeicherung
* XML als Datenaustauschformat
* XHTML als Dokumentenformat fuer Browser (an sich weniger ein Aspekt
von XML, als eine Anwendung)
Der Vorteil an der Ausdrucksmaechtigkeit von XML und den entsprechenden
Sprachen (XPath, XQuery, XSLT, DtD, XML Schema) ist, dass man diese
Trennung nicht machen (was durchaus ein Vorteil bzgl "time to market"
sein kann) muss. Aus den Ideen hinter der Trennung dieser Aspekte
kommen aber einige Entwurfsentscheidungen und Begriffe (Daten/Metadaten),
die dann auch schwer verstaendlich sind.
Andreas Borutta <bor...@gmx.de> wrote:
> Wolfgang May schrieb:
> >> Ich möchte ganz schlicht so wenig Umformungsaufwand wie irgend möglich
> >> betreiben. Bei der Prämisse: Verwendung von FZ-Elementen.
> >
> > Dein Begriff von Umformungsaufwand ist intuitiv begruendet, aber in
> > Wirklichkeit nicht da (wenn Du XSLT verwendest; wenn Du mit Updates
> > tatsaechlich den Baum veraendern wuerdest (und das Ausgangsdokument
> > dabei zerstoeren wuerdest) waere er da):
> >
> > Codierungsaufwand:
> > ob Du einmal die CSS-Darstellungsdefinition entwickelst, oder
> > einmal ein XSLT-Template, ist egal.
>
> Da stimme ich nicht zu.
>
> Eine CSS-Regel für (um beim Beispiel zu bleiben) das Element, welches
> den Interview-Inhalt enthält, muss eh formuliert werden.
Das ist die Frage, wenn Du mit einfachen HTML-Mitteln, <b>, <em>
und Strukturierung <br>, ggf <ul>,<li> auskommst.
> Eine XSLT-Regel, die "<interview></interview>" umformt zu "<div
> class="interview"></div>" käme dazu.
Nur wenn Du dabei bleibst, <interview> auszuliefern; siehe unten.
Ich glaube, das istd er eigentliche Knackpunkt.
> > Ausfuehrungsaufwand: [...]
> > Darstellungsaufwand fuer den Browser: [...]
> > auch egal. Evtl einfacher wenn erst nach XHTML transformiert
> > wurde, und damit das CSS etwas einfacher ist.
>
> Das ist "Aufwand für Maschinen". Den habe ich bei meinem Argument
> nicht betrachtet.
Ich wusste nicht, welchen Du meinst, deshalb habe ich mal alle
aufgeschluesselt.
In manchen Faellen sollte man auch den Aufwand fuer Maschinen (client. und
serverseitig) nicht unter den Tisch fallen lassen (ich hasse online-Banking,
was stundenlang mit Aufbau von Gedoens beschaeftigt ist ;) Sollte aber
hier wirklich venachlaessigbar sein.
> >> Zugänglichkeit betreffen, auch beim Ausliefern, so wenig wie möglich
> >> von dieser Anreicherung "vernichten" (durch Umwandlung).
> >
> > Wer hat nachher was von dem angereicherten Dokument? Wenns sowieso
> > an den Browser geht, ist es egal.
>
> Vorrangig geht es mir um eine grundsätzliche Leitlinie:
> "Konstruiere ein System nur gerade so komplex wie nötig."
... aber so komplex wie notwendig ;)
> Eine System mit einer XSLT-Umformung ist komplexer als eines ohne eine
> solche Umformung.
Ganz ohne: ja. Bis jetzt sah es aber ja eher so aus, dass Du eine
XML-Repraesentation intern hast, den auszuliefernden "Zwitter", und
das schlussendliche XHTML(+CSS) fuer den Browser
> > Wenn jemand noch damit arbeiten soll, waere es besser ihm gleich
> > das Ausgangsdokument mit allem zu schicken.
>
> Das wäre ein weiteres Argument.
>
> Wenn ich "<interview></interview>" statt "<div
> class="interview"></div>" ausliefere, muss niemand umständlich "nach
> dem Ausgangsdokument fragen".
>
> Anders:
> Die "hochwertige" Form des Dokumentes ist die ausgelieferte,
> öffentlich verfügbare Version.
> Das gefällt mir.
OK. Ist IMHO die absolut optimalste.
Es gibt dann sozusagen nur Dein Original-XML-Dokument, und
die HTML(+CSS)-Version, die im Browser angezeigt wird.
Bleiben die praktischen Fragen dazu (siehe auch ganz unten).
> >> ***
> >> Angabe der XHTML-plus-FZ-DTD im Dokumentkopf
> >> ***
>
> Mir ist noch nicht klar, wie man eine "angereicherte Kopie der
> W3C-DTD" praxistauglich angibt.
>
> So
>
> http://borumat.de/xml-test/xhtml1-strict-plus-fz/
> | <?xml version="1.0"?>
> | <?xml-stylesheet type="text/css" href="default.css" ?>
> | <!DOCTYPE html SYSTEM "default.dtd">
> | <html>
> | <head>
> | <title>Foo</title>
> | </head>
> | <body>
> | <h1>Foo</h1>
> | <interview>Interview</interview>
> | </body>
> | </html>
>
> geht es jedenfalls nicht.
>
> FF stellt so "title" nicht wie erwünscht dar.
Ja, auch bei mir nicht.
Zeigt schwarz "foo foo" (in normalschrift), dann in der Zeile darunter "interview" (in rot)
an.
> Und es wird auch kein Useragent-Stylesheet angewendet.
Doch, bei mir ist interview rot (aber die ueberschrift halt nicht fett, und das head-Foo
wird mit dargestellt.
Wenn ich dasselbe unter
http://user.informatik.uni-goettingen.de/~may/test/foo-original.html
ablege (default.dtd liegt daneben)
[Nur als Hinweis: html ist in Deiner default.dtd ja wie im W3C-Original definiert,
mit
<!ATTLIST html
%i18n;
id ID #IMPLIED
xmlns %URI; #FIXED 'http://www.w3.org/1999/xhtml'
>
=> mit xmlns="..." "weiss" der Browser, dass es sich um das html-Element
aus dem originalen XHTML(-Namespace) handelt.
]
zeigt mein Browser "Foo" fett, in linebreak mit mehr Abstand, und "interview"
nicht-fett (aber auch nicht rot) an.
Bei
http://user.informatik.uni-goettingen.de/~may/test/foo2.html
habe ich das css als <style> reinkopiert, und dann ist "interview" auch rot.
Also: Die Einbindung des Stylesheets wird ignoriert.
Anstatt die processing instruction <?...?>
habe ich auf
http://user.informatik.uni-goettingen.de/~may/test/foo-link.html
mal die Alternative
<link rel="stylesheet" type="text/css" href="default.css"/>
ausprobiert ==> geht (aehm, zumindest bei mir).
(an sich sollten beide gehen, und das <link> sollte nach W3C eigentlich innerhalb
des html stehen).
=> Erfahrungen dieser Art waren AFAIR damals der Grund, warum ich css in der Vorlesung
nicht behandele und auch bei meinen Webseiten nicht verwende.
> >> Die Nachteile anders ausgedrückt:
> als Trennzeichen für Werte verwendet werden.
>
> Dass XPath nicht "von Hause" aus auf die einzelnen Werte zugreifen
> kann, werte ich als Indiz dafür, dass es sich um ein "Improvisieren"
> handelt.
Jein.
Fuer IDREFS (z.B. <organization members="D CH A ...">) ist es OK
(und notwendig, wenn man DTD und nicht XML Schema benutzt), die sind
vollwertige Mitglieder im XML-Datenmodell.
NMTOKENS fallen raus. Sie sind nur dort nutzbar, wo eine Konvention
besteht, dass das verarbeitende Tool in einer allgemeinen
Programmiersprache geschrieben ist, die auf Stringmanipulationsebene
arbeitet.
Aus einer anderen Perspektive soll man aber halt Metadaten als
Attribute ablegen, d.h., fuer mehrwertige Metadaten-Attribute bleibt
da nur NMTOKENS. (Man haette die XPath-Semantik da auch entsprechend
entwerfen koennen [sollen?], dass sie bei entsprechendem Wissen aus
der DTD mehrere name-wert-Paare zurueckgibt, und nur beim
Wiederanhaengen an ein Element alle wieder als NMTOKENS in ein
Attribut packt).
> > Was Du meinst, ist dass Du bestimmte Dinge, die eigentlich Metadaten
> > zum Text sind (Datum des Interviews) in der Auslieferung zum
> > Text hinzunehmen willst. Da spricht nichts dagegen, aber damit wechseln
> > die Metadaten sozusagen die Seite:
> > Bei
> > <interview mit="Karl Napf" datum="1.1.2011">
> > <Frage> Herr Napf, wie sehen sie das?</Frage> ... </>
> > ist die Info, dass das Interview mit Karl Napf ist und am 1.1.2011
> > gemacht wurde, Metadaten. Wenn Du das als
> > <h2>Interview mit <font color="red">Karl Napf</font> am 1.1.2011</h2>
> > auslieferst, ist der Text "Interview mit Karl Napf am 1.1.2011"
> > die Daten, und die Tatsache, dass Karl Napf in rot gesetzt wird,
> > Metadaten. Der Effekt ist, dass ein dummer Browser immerhin noch
> > "Interview mit Karl Napf am 1.1.2011" ausgibt, und nicht
> > "Interview mit red Karl Napf am 1.1.2011".
>
> Ein wesentliches Ziel von gutem Markup ist Langlebigkeit.
> Es soll für vielfältigste Zwecke verwendbar sein, ohne dass man es
> erneut "anfassen" muss.
Ja, sicher. Auf der anderen Seite ist es auch gut, zu wissen, welche
Verfeinerungen ggf. wie (und wie einfach) zu realisieren sind.
> Attribute erfüllen das Merkmal nicht.
> Sie engen erstens ein, weil sie bestimmte Formen der Darstellung
> verhindern.
> Sie engen zweitens ein, wenn das Dokument ergänzt wird. Mit weiteren
> Inhalten. Mit Inhalten, die plötzlich eine Substruktur erfordern.
> Dann müsste man das Attribut "wegwerfen" und "in einem Element
> umwandeln".
> Unschön. Verlust von Flexibilität.
Jein. Auch Gewinn: Separierung von Daten (Elemente, bzw Textinhalte
von Elementen) und Metadaten (Attribute).
Hier nochmal ein Anwendungsbeispiel, in dem es sehr sinnvoll ist,
Medadaten/Annotationen als Attribute und echten "Inhalt" als Inhalt zu
haben:
<warteschlange datum="01-01-2011" bearbeitet="26-12-2010" ...>
<einkaufen was="eier"/>
<putzen was="kueche"/>
:
</>
Mit //Warteschlange/*[1] kann man sich das erste Element geben lassen (man
weiss nicht, was sein Elementname ist). Haette man jetzt datum, bearbeitet
etc auch als Attribute muesste man diese
//Warteschlange/*[not (name()="datum" and not name()="bearbeitet" and not ...][1]
explizit ausschliessen (und jedesmal nachfuddeln, wenn man mal ein Attribut
neu in die DTD aufnimmt). Als "Warteschlange" sind die Einraege die Daten,
und die Informationen ueber die Warteschlange als ganzes die Metadaten.
Das hat also garnichts mit Wichtigkeit zu tun (das Datum, fuer welchen
Tag sie Auftraege sind, ist sehr wichtig, waehrend die Information,
wann der letzte Eintrag gemacht wurde, eigentlich voellig irrelevant ist).
(Analoge Fragestellung bei Dir: "gib mir die erste Zeile des Interviews
//interview/*[1] geht genau dann, wenn das der erste Satz ist, der wirklich
faellt, und nicht irgendein Metadaten-Gedoens des Interviews)
Beim Entwurf einer DTD muss man daher mehrere, sich manchmal auch
widersprechende Aspekte beruecksichtigen, und etwas vorausschauen (und
muesste dazu auch die verwendeten Sprachen kennen), was wohl mal
gebraucht wird, bzw damit gemacht werden soll.
(umgekehrt: XML ist so gestaltet, dass eine spaetere Aenderung oft
lokal korrigierbar ist)
> Erst wenn eine "Transformations-Maschine" das Markup manipuliert, kann
> man bestimmte Darstellungsziele bzw. die Substruktur erreichen.
>
> Und genau diesen Zwang zur Verwendung einer "Transformations-Maschine"
> möchte ich ja, wie weiter oben erwähnt, gerade nicht.
Das ist eine weitere Frage, die mit "XML als Speicherungsformat"
und "HTML als Ausgabeformat" (moeglicherweise mehrere HTML-Dokumente
aus demselben XML-Datendokument) zusammenhaengt.
An sich ist die Trennung aus Speicherung->Transformation(en)->Ausgabe(n)
eine der Staerken der XL-Welt.
Stell' die grob vor, eine Uni, die alle Daten zu Lehrveranstaltungen
in einem Dokument zentral speichert. Daraus koennten dann Vorlesungs-
verzeichnisse, Modulkataloge, Raumplaene, Stundenplaene etc durch
Transformationen generiert werden. Uebertragung auf Deinen Fall:
alle Daten zu haben (Speicherung), aber unterschiedlich aufbereitet
darstellen zu koennen.
> Noch kenne ich keine glasklare scharfe Definition für "Bei diesem
> Inhalt handelt es sich um Metadaten" und "Bei diesem Inhalt handelt es
> sich um Daten".
> Dabei soll sich die Entscheidung an der Semantik festmachen und nicht
> an späteren, möglichen Ausgabevarianten.
Die Unterscheidung ist manchmal nicht scharf (und wird ausserdem durch
o.g. Diskussion, dass Attribute nicht strukturiert sein koennen torpediert).
Wenn man mit den Begriffen "Daten" und "Metadaten" mal warmgeworden ist,
erleichtern sie oft ein gutes Design (und damit die spaetere Arbeit mit
etwas) deutlich. Fuer Neulinge sind sie aber oft zuerst nur verwirrend.
Am Beispiel des Interviews: Daten ist das, aus was das Interview (z.B.
als Radiointerview) bestehen wuerde. Metadaten sind das, was der
Kommentator/Reporter *dazu* sagt "dieses Interview wurde am ... mit
... aufgenommen". Je mehr man von Dokumentorientierung weg zu
Datenorientierung geht, desto mehr verschwindet der Unterschied
zwischen Daten und Metadaten (vgl. mein Mondial-Beispiel).
Umgekehrt gibt es z.B.die Shakespeare-Theaterstuecke als XML
(google nach hamlet.xml) ohne Verwendung von Attributen (IMHO kein
Musterbeispiel einer DTD, weil eben Textzeilen und Metadaten beides als
Daten vermischt werden).
Zurueck zu der Frage, was Du wie auslieferst:
Es gibt auch die Moeglichkeit ein XML-Dokument komplett in der "internen"
XML-Variante auszuliefern, und ein XSLT-Stylesheet damit zu assoziieren,
das bei Browserzugriff aufgerufen und ausgefuehrt wird:
Greif mal auf
http://ap34.ifi.informatik.uni-goettingen.de/SSDXML/mondial-with-stylesheet.xml
zu. Du siehst eine Tabelle; wenn du "show source" im Browser machst, siehst
Du das originale XML-Dokument.
(Mit dem Stylesheet koenntest Du natuerlich dann auch noch
css-<link>-Elemente einfuegen.
Risiko: wenn es nicht funktioniert. Wegen dem verwende ich bei den
Arbeitsgruppen-Webseiten das "unprofessionelle" Verfahren, die
HTML-Seite aus dem XML statisch zu generieren und auf den Webserver zu
packen (entsprechend kann man zu den meisten Seiten anstatt bla.html
auch bla.xml auf dem Server finden).
Momentan denkst Du im wesentlichen daran, einzelne Dokumente (Z.B. Interviews)
zu haben und darzustellen. Mittelfristig leifert XML Dir aber auch die Moeglichkeit,
Listen und Zusammenstellungen von Dokumenten nach Datum, Thema, "Thread" etc.
zusammenzustellen. Das waere dann auf jeden Fall ein Fall fuer XSLT, bei der
aus der gespeicherten Daten (bzw Dokumenten)-Basis Web-Inhalte generiert werden.
Wolfgang