Diskussion zu: Webkompetenz-Blog wandert ins Wiki -- Feeds?
david...@gmail.com
ersetzen. So gibt es dort keine Ping-/Trackbacks und keine
Möglichkeit, die Beiträge als Feed zu abonnieren."
Zu (meinem) Glück habe ich doch gleich eine Möglichkeit gefunden, den
"Blog-Feed" zu ersetzen -- dachte ich, als ich auf der Seite "Recent
Changes" (http://webkompetenz.wikidot.com/system:recent-changes) die
Möglichkeit sah, dass man nach Kategorien wie "Spot" sowie nach "Neu"
angelegten Seiten filtern kann. Leider sind die Filter aber nicht als
Feed verfügbar; in diesem sind wirklich alle Änderungen, und das ist
mir zu viel... Jetzt bleibt mir doch wohl nicht erspart, selbst
regelmäßig nach Neuem Ausschau halten zu müssen, wie früher halt... :-
(
Ansonsten aber lese ich Stefans Blog mit sehr viel Interesse, danke!
Gruß,
David
j9t
> ersetzen. So gibt es dort keine Ping-/Trackbacks und keine
> Möglichkeit, die Beiträge als Feed zu abonnieren."
Weder Feed noch Newsletter wäre wirklich bedauerlich; vielmehr
essentiell ...
Stefan Münz
> Weder Feed noch Newsletter wäre wirklich bedauerlich; vielmehr
> essentiell ...
Mittlerweile gibt es einen Feed der Spots, also von den Beiträgen, die
vorher im Blog gelandet wären:
http://webkompetenz.wikidot.com/local--files/spots/spots.xml
viele Grüße
Stefan Münz
Dirk Ruchatz
> Mittlerweile gibt es einen Feed der Spots, also von den Beiträgen, die
> vorher im Blog gelandet wären:http://webkompetenz.wikidot.com/local--files/spots/spots.xml
das sind ja gute Nachrichten (und noch dazu schneller, als
erwartet) ;-)
Ich hatte schon versucht, aus der Wiki-Startseite automatisch eine XML-
Datei für einen Feed zu generieren, bin aber letztlich daran
gescheitert, dass sich mit jedem neuen Spot auch der Aufbau der Seite
geringfügig geändert hat (IDs, Formatierungen etc.) und somit das
eindeutige Kriterium fehlte...
Jetzt kann ich mir die Arbeit ja sparen <g>
Glück auf
Dirk
konnexus
Stefan Münz
> Ich hatte schon versucht, aus der Wiki-Startseite automatisch eine XML-
> Datei für einen Feed zu generieren, bin aber letztlich daran
> gescheitert, dass sich mit jedem neuen Spot auch der Aufbau der Seite
> geringfügig geändert hat (IDs, Formatierungen etc.) und somit das
> eindeutige Kriterium fehlte...
Jepp, diese Services wie http://page2rss.com/ basieren auf festen
Verhältnissen im Markup der Quellseite. Bei der Startseite im Wiki
ändere ich jedoch bei jedem Spot die Prozentwerte der Breiten der div-
Bereiche, damit die Spalte mit dem Inhaltsverzeichnis und die mit dem
aktuellen Spot ungefähr gleich lang sind.
Den Feed pflege ich jetzt händisch, also mit Editor und XML-Quelltext.
So komme ich wenigstens nicht aus der Übung, wenn ich sonst schon nur
noch Wiki-Markup benutze ;-)
viele Grüße
Stefan Münz
mariansigler
> Den Feed pflege ich jetzt händisch, also mit Editor und XML-Quelltext.
> So komme ich wenigstens nicht aus der Übung, wenn ich sonst schon nur
> noch Wiki-Markup benutze ;-)
Eine kleine Bitte, dann bin ich mit dem neuen Feed zufrieden ;-) :
Kannst du das Datum "richtig" hinschreiben, nämlich nach RFC 822
(http://ietf.org/rfc/rfc822,
http://validator.w3.org/feed/check.cgi?url=http://webkompetenz.wikidot.com/local--files/spots/spots.xml)?
Dann akzeptiert es nämlich mein Feedreader (und das Teil ist schon
mehr valide, und invalide Feeds sind nun wirklich nicht Stefan-Münz-
gerecht ;-) )
grüße, maix
Stefan Münz
> Eine kleine Bitte, dann bin ich mit dem neuen Feed zufrieden ;-) :
> Kannst du das Datum "richtig" hinschreiben, nämlich nach RFC 822
> (http://ietf.org/rfc/rfc822,http://validator.w3.org/feed/check.cgi?url=http://webkompetenz.wikido...
> Dann akzeptiert es nämlich mein Feedreader (und das Teil ist schon
> mehr valide, und invalide Feeds sind nun wirklich nicht Stefan-Münz-
> gerecht ;-) )
Wenns nur das Datum wäre, das eh schon in einem internationalen Format
ist (z.B. 2007-10-18). Warum soll ich mich von einem Validator zwingen
lassen, bei jedem Posting meine Mailadresse mit anzugeben? Und warum
soll ich bei <guid> jedesmal einen URN nach einem hirnrissigen Schema
verwenden, statt mit einfacher Nummerierung der Pflicht des Feldes
nach dokumentweit eindeutigem Inhalt Genüge zu tun? Um ehrlich zu
sein, bitte ich um triftige Argumente, das alles zu tun. Ich lebe
übrigens seit Monaten mit für den Validator invaliden Inhalten (z.B.
diese Google Group hier, deren Source wie bei jeder Google Group
etliche Fehler produziert). Und es hat sich noch kein einziger
Accessibility-Betroffener bei mir beschwert. Wenn ich genügend Wein
getrunken habe, wage ich fast zu dem ketzerischen Gedanken zu neigen,
dass der Validator ein gutgemeintes Instrument für spezielle
Einsatzzwecke ist, das aber vor allem von der deutschen Ordnungsmafia
verhätschelt wird, die sich beileibe nicht nur in Polizei- und
rechtsradikalen Schlägerkreisen manifestiert, sondern eben auch in
zahlreichen Zwangsvorstellungen wie eben der, dass HTML-Fehlertoleranz
per se böse ist. Nein, ich bin nicht von Firefox 2 auf MS IE 6
umgestiegen - ich will nur mal ein wenig gegen einen Strom schwimmen,
der mir seit geraumer Zeit etwas auf den Senkel geht. Das ist auch
keineswegs gegen dich persönlich gemeint, Marian!
viele Grüße
Stefan Münz
Tim
(ich ordne Deine Zitate mal um, sorry)
> (...) dass der Validator ein gutgemeintes Instrument für spezielle
> Einsatzzwecke ist, das aber vor allem von der deutschen Ordnungsmafia
> verhätschelt wird, (...)
Das ist zwar eine nette Verschwörungstheorie; in diesem Fall solltest
Du dieser aber nicht anhängen. Der Validator ist tatsächlich gut
gemeint – in dem Sinne, dass dieser nicht nur abstrakte Syntax nach
SGML/XML/RELAX/Whatever überprüft, sondern versucht, tatsächlich aus
der Praxis entstandene Tipps unterzubringen versucht. Ein maschineller
Feed-Experte sozusagen. Sprich: Er versucht zu helfen; dummerweise
wird Hilfe oft als bevormundend empfunden.
Das mag jetzt idealisierend klingen, aber tatsächlich kommen wirklich
viele der Ratschläge aus schlechten Erfahrungen und dem Vergleich der
Möglichkeiten meist gebräuchlicher Feedreader. Zum Beispiel hat der
originale Feedvalidator (den das W3C einfach installiert hat) diese
Woche ein Update von Ratschlägen bekommen, die im RSS Advisory Board
als RSS Profile erarbeitet wurden. (Die „Legitimität” des RSS Boards
ist wegen der absurden „Standard-Geschichte“ umstritten, an der
jahrelangen Praxiskenntnis der dort Beteiligten disputiert jedoch
keiner.)
Um mal Deine konkreten Probleme mit Hintergrund auszustatten:
> Wenns nur das Datum wäre, das eh schon in einem internationalen Format
> ist (z.B. 2007-10-18).
Dummerweise steht in der RSS Spezifikation nun mal RFC 822-konformes
Datum (mit all dessen bekannten Schwächen). Wenn sich nun irgendein
Hobbyentwickler die Spezifikation durchliest, einen XML-Parser
schnappt und versucht aus Deinem ISO 8601-Datum einen maschinellen
Timestamp zu machen, wird er nun mal scheitern → Datenverlust.
Bei RSS 2.0 ist nun mal RFC 822 verpflichtend, weil draussen
haufenweise Software ist, die das RFC 822-Format erwartet. Genauer
erwartet sie eine ganz bestimmte Teilmenge von RFC 822, weil jeder
Hans und Wurst seine eigene Interpretation davon hat und nicht jeder
Feedreader alles kann; das oben erwähnte RSS Profil und damit auch der
Feedvalidator versucht Dich darauf hinzuweisen.
Das Datumsformat nach ISO 8601 / RFC 3339 wird so übrigens in Atom
verwendet.
> Warum soll ich mich von einem Validator zwingen lassen,
> bei jedem Posting meine Mailadresse mit anzugeben?
Hier ist dasselbe Problem wie beim Datum: Die Erwartungshaltung der
Software. RSS 2.0 spezifiziert nun mal eine E-Mail-Adresse, jahrelange
Tradition sagt E-Mail-Adresse im Format nach RFC 822 (das so nirgendwo
spezifiziert ist; man muss das wissen). Wenn diese E-Mail-Adresse
nicht da ist, hat man keine große Möglichkeit, den Autor anzugeben →
theoretischer Datenverlust.
Der Workaround in der absurden RSS-2.0-Welt war übrigens in den
letzten Jahren, das Element <author> mit dessen absurder E-Mail-
Adressen-Bedingung wegzulassen, sondern stattdessen den Dublin Core
Namensraum einzubinden und daraus <dc:creator> zu verwenden. Dublin
Core verstehen die meisten Feedreader – hier wieder aus jahrelanger
Tradition. Solch ein Feed kriegt übrigens die technische
Fachbezeichnung „funky“.
In Atom gibt es keine solche E-Mail-Bedingung; schließlich wollte man
das bessere RSS machen. Dort kann man nach Belieben
<author><name>Stefan Münz</name><uri>http://webkompetenz.wikidot.com/</
uri></author> machen.
> Und warum soll ich bei <guid> jedesmal einen URN nach einem hirnrissigen Schema
> verwenden, statt mit einfacher Nummerierung der Pflicht des Feldes
> nach dokumentweit eindeutigem Inhalt Genüge zu tun? Um ehrlich zu
> sein, bitte ich um triftige Argumente, das alles zu tun.
Dazu muss ich wieder ausholen; der Grund ist aber triftig, wenn er
auch weit hergeholt zu scheinen mag.
Du veröffentlichst Deinen Feed mit dem Schema <guid>1</guid>. Das
entspricht übrigens wieder nicht der RSS Spezifikation – dort wird bei
Fehlen des Attributes isPermaLink="false" angenommen, dass die GUID
dann die URL des Originaleintrages wäre. In Deinem Fall dann die
Adresse des Spot-Eintrages in Deinem Wiki. Nun ist „1“ keine wirkliche
URL → Nicht-Erfüllen der Erwartungshaltung → Nicht-Funktionieren von
mancher Software. Wenn auch sehr zickiger Software, denn – wieder aus
Tradition wird oft <link> bevorzugt, auch wenn die Spezifikation was
anderes sagt. (Der GUID-Streit von 2003).
Nehmen wir mal an, Du veröffentlichst den Feed mit <guid
isPermaLink="false">1</guid>. Hier hast Du dokumentenweite
Eindeutigkeit. Wenn Du nun einen Tippfehler verbesserst, wird der von
besseren Feedreadern als der gleiche Eintrag wie beim vorherigen Holen
des Feedes wahrgenommen statt einem neuen Eintrag. Dafür dient ja die
GUID, zur eindeutigen Identifizierung von Einträgen.
Was ist nun, wenn Dein Eintrag woanders im Netz auftaucht? Zum
Beispiel, wenn Dein Feed in einem Planet, Feedsammler (wie Bloglines
oder ähnliches) reinkommt. Nehmen wir mal ein hypothetisches
planet.selfhtml.org an, das sämtliche Blogs von SELF-nahen Personen
sammelt und als Gruppe wiederveröffentlicht. Auch als Feed wieder
veröffentlicht. Weil mal Metadaten bewahren möchtet, wird Dein Eintrag
im neuen Feed so wieder veröffentlicht, mit der GUID von 1. Und nun
beginnt Thomas J.S. mit dem Bloggen und hat das gleiche GUID-Schema.
Was passiert nun, wenn ein Feedreader den Planet-Feed abonniert und
Deinen Eintrag verarbeitet hat. Und nun kommt Thomas' Eintrag und er
muss den verarbeiten. Ist das nun ein neuer Eintrag, der zufällig die
gleiche GUID hat? Oder ist das der gleiche Eintrag wie Deiner, in dem
zufällig sämtliche Daten, Titel, Text, Link verändert wurden? Common
Sense sagt in diesem Fall natürlich ersteres. Allerdings sind die
Anwendungen von Feeds heutzutage so verschieden, dass man oft nicht
diesen Common Sense zur Verfügung hat; zwei Einträge unterscheiden
sich z.B. bei Linklisten nur minimalst, so dass man oft nicht die
Heuristiken zur Verfügung hat, solchen Common Sense nachzubilden.
Und dafür steht dann das „G“ in GUID – für globale Eindeutigkeit – so
dass man immer die Möglichkeit hat, einen Feed-Eintrag eindeutig zu
identifizieren, egal wo er auftaucht oder wo er sonst noch verwurstet
wird. Globale eindeutige Bezeichner hat man schon mit URLs, also nimmt
man einfach den Permalink des Eintrages.
(Nebenbei Ein neues GUID-Schema des Planets/Feedaggregators wäre eine
nicht so tolle Idee, denn was passiert, wenn Dein Eintrag in Planet
SELFHTML und Planet Webkompetenz auftaucht und jemand beides abonniert
hat? Wieder zwei unterschiedliche Einträge, die nach menschlichem
Ermessen wieder die selben sind.)
...
Ich weiss nicht, welches „absurde URN-Schema“” Du meinst. Verbreitet
im Feed-Umfeld ist die Tag URI (RFC 4151), nach der Form
tag:webkompetenz.wikidot.com,2007-10-20:dingsbums – meinst Du diese?
Wenn ja – auch dieses Schema hat einen Grund, wenn auch einen nicht so
triftigen. Es wird damit einfach versucht der globalen Eindeutigkeit
noch eine zeitliche Eindeutigkeit hinzuzufügen, indem man in den
Bezeichner einen Timestamp einfügt. Der Gedanke dahinter ist, dass man
ja nicht auf immer und ewig die URL-Benennungsgewalt innerhalb einer
bestimmten Domain hat – d.h. sehr theoretisch könnte es dazu kommen,
dass der Bezeichner irgendwann wieder für etwas anderes verwendet
werden könnte. Ok, das ist ein extremer Grenzfall; es kommt aber vor.
Man könnte auch UUIDs nach uuid:006a3e46-f751-4cac-80f9-79de82244836
nehmen. Menschliche Lesbarkeit ist damit komplett dahin, aber es geht
hier ja nur um Maschinen, die miteinander kommunizieren.
> Ich lebe übrigens seit Monaten mit für den Validator invaliden Inhalten (z.B.
> diese Google Group hier, deren Source wie bei jeder Google Group
> etliche Fehler produziert). Und es hat sich noch kein einziger
> Accessibility-Betroffener bei mir beschwert.
Ich schrieb oben mehrmals von Datenverlust. Tatsächlich ist es jeweils
nur minimaler Datenverlust; es geht ja nur jeweils um ein nicht so
relevantes Metadatum. Nichtsdestotrotz ist es ein Verlust und manchmal
hat man Anwendungen, die genau diese Metadaten brauchen, weil sie
irgendwas spannendes (oder totlangweiliges) damit machen. Z.B. ein
Feedaggregator, der anhand des Datums versucht rauszukriegen, wann ein
bestimmtes Meme in der Blogosphäre populär wird und wie lange es
andauert. Oder ein Aggregator, der aus den Kategorien verschiedener
Blogs bzw. deren Feeds versucht Topic Maps zu erstellen (Hallo Jörg!).
Maschinen sind manchmal wirklich auf Nicht-Datenverlust angewiesen; im
Gegensatz zu Menschen sind sie nicht so fehlertolerant. Und wenn es
keine wirkliche große Anstrengung macht, ein Besser als ein Gerade Gut
Genug zu erreichen, kann man das durchaus tun. Der Feedvalididator
(beide, es gibt ja noch den von Validome) ist dabei eine gute
Hilfestellung. Man muss ihm nur vertrauen.
> (...) sondern eben auch in zahlreichen Zwangsvorstellungen wie eben der,
> dass HTML-Fehlertoleranz per se böse ist.
Ist sie ja nicht. Beliebigkeit ist allerdings zu vermeiden. Im RSS-
Umfeld z.B. ist ein View Source manchmal nicht so toll. Als
Programmierer eines Feedreaders sollte man sich schon mit den
Spezifikationen auskennen. Und den Profilen. Und den tatsächlichen
Kapazitäten von Feedreadern. Und den diversen Kommentaren von Dave
Winer, die er in seinem verschiedensten Blogs zu verschiedensten
Zeiten geäußert hat. Idealerweise auch mit den RSS-Diskussionen der
Jahre 2001 und 2003. Sprich: RSS richtig zu verarbeiten ist durchaus
ein ziemliches Stück orale Tradition – und manchmal grenzt das an
Beliebigkeit.
Die Anstrengungen rund um HTML 5 bedeuten ja auch nicht plötzlich
„Alles ist erlaubt“, sondern man versucht vielmehr seit zwei Jahren
ein definierte Fehlertoleranz ausgehend von den tatsächlichen
Varianten der verschiedenen Browser zu spezifizieren, um Beliebigkeit
aufgrund eines großen gewachsenen Durcheinanders zu vermeiden. O-Ton:
„Damit die Dokumente von heute auch noch in vielen, vielen Jahren
gelesen werden können, ohne rumraten zu müssen.“
Tim
Stefan Münz
bin ja richtig überrascht, dich hier zu lesen! :-)
> > (...) dass der Validator ein gutgemeintes Instrument für spezielle
> > Einsatzzwecke ist, das aber vor allem von der deutschen Ordnungsmafia
> > verhätschelt wird, (...)
>
> Das ist zwar eine nette Verschwörungstheorie; in diesem Fall solltest
> Du dieser aber nicht anhängen. Der Validator ist tatsächlich gut
> gemeint – in dem Sinne, dass dieser nicht nur abstrakte Syntax nach
> SGML/XML/RELAX/Whatever überprüft, sondern versucht, tatsächlich aus
> der Praxis entstandene Tipps unterzubringen versucht. Ein maschineller
> Feed-Experte sozusagen. Sprich: Er versucht zu helfen; dummerweise
> wird Hilfe oft als bevormundend empfunden.
In meinem gestrigen Posting war ich in der Tat etwas rüde gegen den
Vali. Mittlerweile habe ich die angemeckerten Fehler im Feed bis auf
die Mailadresse, was ich wirklich nicht einsehe, ja auch korrigiert -
so viel zu meiner Entschuldigung ;-)
> > Wenns nur das Datum wäre, das eh schon in einem internationalen Format
> > ist (z.B. 2007-10-18).
>
> Dummerweise steht in der RSS Spezifikation nun mal RFC 822-konformes
> Datum (mit all dessen bekannten Schwächen). Wenn sich nun irgendein
> Hobbyentwickler die Spezifikation durchliest, einen XML-Parser
> schnappt und versucht aus Deinem ISO 8601-Datum einen maschinellen
> Timestamp zu machen, wird er nun mal scheitern → Datenverlust.
OK, habe ich eingesehen. Ich finde zwar halt Angaben nach RFC 822
nicht redaktionell, sondern eben wie du treffend sagst maschinell
orientiert. In der Regel können Autoren davon verschont werden, weil
sie die Feeds nicht direkt editieren. In diesem Fall kann die
Interface-Anwendung, die Benutzereingaben in den Feed schreibt, für
eine Konvertierung von ISO 8601 nach RFC 822 sorgen.
> Hier ist dasselbe Problem wie beim Datum: Die Erwartungshaltung der
> Software. RSS 2.0 spezifiziert nun mal eine E-Mail-Adresse, jahrelange
> Tradition sagt E-Mail-Adresse im Format nach RFC 822 (das so nirgendwo
> spezifiziert ist; man muss das wissen). Wenn diese E-Mail-Adresse
> nicht da ist, hat man keine große Möglichkeit, den Autor anzugeben →
> theoretischer Datenverlust.
Das möchte ich zumindest mal testen. Mal sehen, ob ich jetzt immer
noch Feedback bekomme von Usern, die den Feed nicht einbinden können,
weil die Mailadresse fehlt.
> Der Workaround in der absurden RSS-2.0-Welt war übrigens in den
> letzten Jahren, das Element <author> mit dessen absurder E-Mail-
> Adressen-Bedingung wegzulassen, sondern stattdessen den Dublin Core
> Namensraum einzubinden und daraus <dc:creator> zu verwenden. Dublin
> Core verstehen die meisten Feedreader – hier wieder aus jahrelanger
> Tradition. Solch ein Feed kriegt übrigens die technische
> Fachbezeichnung „funky“.
Gar keine schlechte Idee, Dublin Core hierfür zu verwenden. Wird da
tatsächlich das gesamte Dublin-Core-Set interpretiert? Denn das
ermöglicht ja interessante semantische Informationen wie DC.type,
DC.language, DC.coverage, DC.rights usw.
> In Atom gibt es keine solche E-Mail-Bedingung; schließlich wollte man
> das bessere RSS machen. Dort kann man nach Belieben
> <author><name>Stefan Münz</name><uri>http://webkompetenz.wikidot.com/</
> uri></author> machen.
Mal sehen, vielleicht steige ich ja auf Atom um - da ichs von Hand
editiere, könnte ich ja ebensogut Atom verwenden. Es erschien mir nur
auf den ersten Blick etwas aufwändiger.
> Was ist nun, wenn Dein Eintrag woanders im Netz auftaucht? Zum
> Beispiel, wenn Dein Feed in einem Planet, Feedsammler (wie Bloglines
> oder ähnliches) reinkommt. Nehmen wir mal ein hypothetisches
> planet.selfhtml.org an, das sämtliche Blogs von SELF-nahen Personen
> sammelt und als Gruppe wiederveröffentlicht. Auch als Feed wieder
> veröffentlicht. Weil mal Metadaten bewahren möchtet, wird Dein Eintrag
> im neuen Feed so wieder veröffentlicht, mit der GUID von 1. Und nun
> beginnt Thomas J.S. mit dem Bloggen und hat das gleiche GUID-Schema.
Jo, das ist mir mittlerweile auch eingefallen. Wenn der Feed in die
Mühlen des Content Syndications gerät, ist dokumentweite Eindeutigkeit
natürlich nicht mehr ausreichend, dann muss es globale Eindeutigkeit
sein. Und die geht eben am einfachsten über URNs. Deshalb habe ich das
mittlerweile auch entsprechend korrigiert.
> Ich weiss nicht, welches „absurde URN-Schema“” Du meinst. Verbreitet
> im Feed-Umfeld ist die Tag URI (RFC 4151), nach der Form
> tag:webkompetenz.wikidot.com,2007-10-20:dingsbums – meinst Du diese?
Nein, das war ein anderes Schema - mit generierten
Zufallszeichenfolgen, so ähnlich wie in einem Registriercode für
Software. Ich hatte das in Beispielen gesehen, die ich zu Rate zog,
finde die aber gerade nicht wieder. Ich hätte vielleicht besser gleich
beim Münz nachschlagen sollen - im Buch "Professionelle Websites"
Auflage 2 ist alles beschrieben, auch das guid-Element - blöd nur,
wenn die Altersdemenz schon so fortgeschritten ist ;-)
> Man könnte auch UUIDs nach uuid:006a3e46-f751-4cac-80f9-79de82244836
> nehmen.
Genau - so was war das in den Beispielen, und das hatte mich einfach
abgestoßen!
> Maschinen sind manchmal wirklich auf Nicht-Datenverlust angewiesen; im
> Gegensatz zu Menschen sind sie nicht so fehlertolerant. Und wenn es
> keine wirkliche große Anstrengung macht, ein Besser als ein Gerade Gut
> Genug zu erreichen, kann man das durchaus tun. Der Feedvalididator
> (beide, es gibt ja noch den von Validome) ist dabei eine gute
> Hilfestellung. Man muss ihm nur vertrauen.
Ja, die unterschiedliche Denke von Menschen und Maschinen ist wohl der
Knackpunkt in dieser Diskussion. Mir ist schon klar, dass ich, wenn
ich den XML-Code eines RSS-Feeds direkt editiere, mich nicht nur an
einen reinen XML-Parser wende, den Zeichendateninhalte von Elementen
nicht weiter interessieren (solange sie CDATA oder PCDATA sind, je
nachdem, was ein Elementinhalt erlaubt), sondern auch an einen
Interpreter, der ähnlich wie die HTML-Interpreter von Web-Browsern
mehr tut als nur parsen: er übersetzt Inhalte. Das dabei auch mal
Konventionen, Constraints oder Schemata beim Zeichendateninhalt nötig
sind, sehe ich durchaus ein. Ich frage mich nur, warum es nicht
möglich sein sollte, einem solchen Inhaltsinterpreter so viel
Intelligenz einzuprogrammieren, dass er "Thu, 18 Oct 2007 12:00:00
+0200" und "2007-10-18" als zwei unterschiedliche Formate anerkennt,
die aber bekannten Regeln entsprechen.
> Die Anstrengungen rund um HTML 5 bedeuten ja auch nicht plötzlich
> „Alles ist erlaubt“, sondern man versucht vielmehr seit zwei Jahren
> ein definierte Fehlertoleranz ausgehend von den tatsächlichen
> Varianten der verschiedenen Browser zu spezifizieren, um Beliebigkeit
> aufgrund eines großen gewachsenen Durcheinanders zu vermeiden.
So verstehe ich das auch. Übrigens habe ich dazu von dir einiges
wirklich Interessantes gelesen, was das Verständnis erhellt. Z.B. habe
ich mich zunächst gefragt, warum die HTML-5-Wirdmalwerden-Spec alle
Elemente als DOM-Konstrukte definiert. Ich habe nirgends einen Hinweis
gefunden über zum Warum dieser Repräsentationsform. Das wurde mir erst
klar durch deinen Hinweis, dass HTML 5 versucht, sich am
Arbeitsspeicherinhalt des Browsers zu orientieren, und nicht an einem
abstrakten, datenverarbeitungsunabhängigen Dokumenttyp. Deshalb auch
keine DTD mehr, sondern stattdessen lieber genaue Vorgaben zur Lösung
von Konfliktfällen. Diesen Weg kann ich nur begüßen. Denn so schön das
Konzept der Dokumenttyp-Definitionen oder Schemata ist: sein Raster
ist noch deutlich zu grob, um daraus immer konkrete if's und else's in
einer konkreten Programmiersprache abzuleiten.
Was ich allerdings noch nicht kapiert habe, wie sie das ohne das
Zusammenspiel mit CSS lösen wollen. Denn ein p oder ein div oder
sonstwas ist einerseits das, was es per HTML-Default ist, aber dank
CSS kann es in der Realtität einer im Arbeitsspeicher repräsentierten
Webseite auch ganz oder teilweise etwas anderes sein (dank solcher
Gemeinheiten wie display:inline, white-space:nowrap usw.).
viele Grüße
Stefan Münz