Problem mit Schema

[Thomas Mell]

Hallo,
ich habe ein Problem beim erstellen eines Schema.
Folgendes kleines XML-Dokument soll als Beispiel herhalten:
<root>
  <title>blabla</title>
  <id>id1</id>
  <link>http://foo.de</link>
  <link>http://foo.de</link>
  <link>http://foo.de</link>
</root>
Das Problem liegt nun darin das die Reihenfolge der Elemente beliebig sein sollen.
"sequence" und "choice" scheiden dafür wohl aus.
Bei "all" ist zwar die Reihenfolge beliebig, es darf aber jedes Element nur einmal vorkommen, was wegen dem <link>-Tag nicht möglich ist.
Ich währe für jede Hilfe dankbar.

Grüße
Thomas

[Gunnar Bittersmann]

Hello out there!

<root>
  <title>blabla</title>
  <id>id1</id>
  <link>http://foo.de</link>
  <link>http://foo.de</link>
  <link>http://foo.de</link>
</root>

Das ist äquivalent zum Inhalt des head-Elements in XHTML 1.0, das genau ein title-Element enthalten muss, dazu beliebig viele link-, meta-, style-, script-, ...-Elemente enthalten darf, und das in beliebiger Reihenfolge.

Da sollte ein Blick in XHTML™ 1.0
in XML Schema helfen, wie’s dort gelöst ist.

See ya up the road,
Gunnar

[Thomas J.S.]

Hallo Thomas,

ich habe ein Problem beim erstellen eines Schema.
Folgendes kleines XML-Dokument soll als Beispiel herhalten:
<root>
  <title>blabla</title>
  <id>id1</id>
  <link>http://foo.de</link>
  <link>http://foo.de</link>
  <link>http://foo.de</link>
</root>
Das Problem liegt nun darin das die Reihenfolge der Elemente beliebig sein sollen.
"sequence" und "choice" scheiden dafür wohl aus.
Bei "all" ist zwar die Reihenfolge beliebig, es darf aber jedes Element nur einmal vorkommen, was wegen dem <link>-Tag nicht möglich ist.
Ich währe für jede Hilfe dankbar.

Wie Gunnar es sagte, es geht dem XHTML-Schema sehr ähnlich:

<xs:element name="root">
    xs:complexType
      xs:sequence
        <xs:element name="link" maxOccurs="unbounded" minOccurs="0" type="xs:anyURI" />
        xs:choice
          xs:sequence
            <xs:element name="title" type="xs:NCName" />
            <xs:element name="link" maxOccurs="unbounded" minOccurs="0" type="xs:anyURI" />
            <xs:element name="id" type="xs:NCName" />
            <xs:element name="link" maxOccurs="unbounded" minOccurs="0" type="xs:anyURI" />
          </xs:sequence>
          xs:sequence
            <xs:element name="id" type="xs:NCName" />
            <xs:element name="link" maxOccurs="unbounded" minOccurs="0" type="xs:anyURI" />
            <xs:element name="title" type="xs:NCName" />
            <xs:element name="link" maxOccurs="unbounded" minOccurs="0" type="xs:anyURI" />
          </xs:sequence>
        </xs:choice>
      </xs:sequence>
    </xs:complexType>
  </xs:element>

Grüße
Thomas

[Thomas Mell]

Hi Thomas,
zunächst einmal vielen Dank für die Hilfe.
So wie ich das sehe gestalten sich solche Regeln doch recht umständlich. Bei meinen einfachen Beispiel ist es ja fast noch vertretbar.
Jetzt stell Dir einmal den Ausdruck vor wenn Du 10 muß-Elemente und noch mal 10 kann-Elemente hast. Wie soll der Ausdruck denn aussehen wenn das alle Childes sind, in beliebiger Reihenfolge auftreten und einige muß-Elemente n-mal auftreten dürfen ?!
Sowohl in dem XHTML-Schema, als auch in Dein Beispiel stehen Auflistungen der verschiedenen Kombinationsmöglichkeiten.
Bei 2 Elementen ist das ja kein Problem, aber bei 10 (oder noch mehr) ?
Gibt es für so etwas keine elegantere Möglichkeit ?

Grüße
Thomas

[Thomas J.S.]

Hallo Thomas,

zunächst einmal vielen Dank für die Hilfe.
So wie ich das sehe gestalten sich solche Regeln doch recht umständlich. Bei meinen einfachen Beispiel ist es ja fast noch vertretbar.
Jetzt stell Dir einmal den Ausdruck vor wenn Du 10 muß-Elemente und noch mal 10 kann-Elemente hast. Wie soll der Ausdruck denn aussehen wenn das alle Childes sind, in beliebiger Reihenfolge auftreten und einige muß-Elemente n-mal auftreten dürfen ?!
Sowohl in dem XHTML-Schema, als auch in Dein Beispiel stehen Auflistungen der verschiedenen Kombinationsmöglichkeiten.
Bei 2 Elementen ist das ja kein Problem, aber bei 10 (oder noch mehr) ?
Gibt es für so etwas keine elegantere Möglichkeit ?

Eine "elegantere" Möglichkeit gibt es nicht.
Was du machen kannst ist verschiedene Gruppierungen zu erstellen und diese dann referenzieren. Das Problem werden aber die muss-Elemente mit n-Vorkommen sein, weshalb ich überlegen würde, ob die beliebige Reihenfolge der Elemente wirklich ein unverzichtbares Kriterium sei.

Grüße
Thomas

[Thomas Mell]

Hallo Thomas,

... weshalb ich überlegen würde, ob die beliebige Reihenfolge der Elemente wirklich ein unverzichtbares Kriterium sei.

Die Vorgaben sind leider so.
Es handelt sich um den kommenden RSS-Validator von Validome.
Momentan sitze ich an den Specs von Atom 0.3 http://www.atomenabled.org/developers/syndication/#requiredFeedElements.
Die Elemente id, title und update müssen vorkommen, aber in beliebiger Reihenfolge. Zusätzlich gibt es noch die optionalen Elemente author, link, category, contributor, generator, icon, logo, rights und subtile, welche zum Teil mehrfach vorkommen dürfen und das auch noch in beliebiger Reihenfolge (jedenfalls sehe ich keinen Hinweis auf eine feste Folge).
So wie das aussieht werde ich dafür wohl ein "weiches" Schema machen müssen und anschließend mit DOM per Hand nachbessern müssen.
Hast Du vieleicht eine Idee ? Es währe kein Problem ein Dokument mehrmals mit DTD's und/oder Schemata (mit DTD's währe es besser, da performanter und die Parsermeldungen Userfreundlicher sind) zu validieren, da die Dokumente i. d. R. nicht sehr groß sind.
Und noch ne Frage.
Es besteht u.a. bei Atom 0.3 die Möglichkeit "Module" einzubinden. Die geschieht über neue Namensräume (z. B. wfw:commentRss).
Der Schemavalidator würde diese Elemente als nicht definiert anmeckern. Da wir die Module vorerst nicht mitvalidieren möchten (schon weil es Unmengen davon gibt, und schon gar keine offizielle Übersicht).
Gibt es ne Möglichkeit solche Namensräume im Schema zuzulassen, sozusagen "alles mit fremden Namensraum" ?

Dank und Grüße
Thomas

[Thomas J.S.]

Hallo Thomas,

... weshalb ich überlegen würde, ob die beliebige Reihenfolge der Elemente wirklich ein unverzichtbares Kriterium sei.
Die Vorgaben sind leider so.
Es handelt sich um den kommenden RSS-Validator von Validome.
Momentan sitze ich an den Specs von Atom 0.3

(http://www.pacificspirit.com/atom/atom3-do.xsd ??)

Aber wieso eigentlich 0.3?
Es gibt zu 1.0 ein RELAX NG (compact)-Schema, vielleicht hilft dir das?
[linkl:http://www.atompub.org/rfc4287.html]

So wie das aussieht werde ich dafür wohl ein "weiches" Schema machen müssen und anschließend mit DOM per Hand nachbessern müssen.
Hast Du vieleicht eine Idee ? Es währe kein Problem ein Dokument mehrmals mit DTD's und/oder Schemata (mit DTD's währe es besser, da performanter und die Parsermeldungen Userfreundlicher sind) zu validieren, da die Dokumente i. d. R. nicht sehr groß sind.

DTD wäre/ist schlicht nicht möglich, denn wenn jemand Elemente aus einem anderen Namesraum als "atom" verwendet, wird der Feed nie im Leben gültig nach der DTD.

Und noch ne Frage.
Es besteht u.a. bei Atom 0.3 die Möglichkeit "Module" einzubinden. Die geschieht über neue Namensräume (z. B. wfw:commentRss).
Der Schemavalidator würde diese Elemente als nicht definiert anmeckern. Da wir die Module vorerst nicht mitvalidieren möchten (schon weil es Unmengen davon gibt, und schon gar keine offizielle Übersicht).
Gibt es ne Möglichkeit solche Namensräume im Schema zuzulassen, sozusagen "alles mit fremden Namensraum" ?

Ja, z.B. mit:
<xs:any processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
(was <xs:any namespace="##any" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> entspricht: ##any = Any well-formed XML from any namespace (default))

Meinst du wirklich ein Schema schreiben zu wollen?
Wäre es nicht einfacher in irgendeiner Sprache einen zugeschnittenen Validator zu schreiben?
Regel wie: "atom:feed elements MUST contain one or more atom:author elements, unless all of the atom:feed element's child atom:entry elements contain at least one atom:author element." sind grausig (wenn nicht unmöglich bei Atom) in Schema umzusetzen.

Grüße
Thomas

[Gunnar Bittersmann]

Hello out there!

[linkl:http://www.atompub.org/rfc4287.html]

Heißt „Link“ auf österreichisch „Linkl“? Ich hätte eher sowas wie „Linkerl“ vermutet.

See ya up the road,
Gunnar

[MudGuard]

Hi,

Heißt „Link“ auf österreichisch „Linkl“? Ich hätte eher sowas wie „Linkerl“ vermutet.

Heißt der Fußballspieler aus Österreich Hans Krankerl oder Hans Krankl?

cu,
Andreas

[Thomas J.S.]

Hallo,

Heißt „Link“ auf österreichisch „Linkl“? Ich hätte eher sowas wie „Linkerl“ vermutet.

Heißt der Fußballspieler aus Österreich Hans Krankerl oder Hans Krankl?

Wenn du ihn schon erwähnst ... weiss du vom 'Schmach von Cordoba'? "I werd narrisch" ;-)

Grüße
Thomas

[Wilhelm Turtschan]

habe d'ehre Thomas

Wenn du ihn schon erwähnst ... weiss du vom 'Schmach von Cordoba'? "I werd narrisch" ;-)

Koenntest Du das bitte bleiben lassen!

man liest sich
Wilhelm

[Thomas J.S.]

Hallo WTU ;-)

Wenn du ihn schon erwähnst ... weiss du vom 'Schmach von Cordoba'? "I werd narrisch" ;-)

Koenntest Du das bitte bleiben lassen!

Sorry, nach diesem WM hätte ich das wirklich bleiben lassen sollen ;-)

Grüße
Thomas

[MudGuard]

Hi,

Wenn du ihn schon erwähnst ... weiss du vom 'Schmach von Cordoba'? "I werd narrisch" ;-)
Koenntest Du das bitte bleiben lassen!
Sorry, nach diesem WM hätte ich das wirklich bleiben lassen sollen ;-)

Wievielter ist eigentlich Österreich geworden bei dieser WM? ;-)

cu,
Andreas

[Wilhelm Turtschan]

habe d'ehre MudGuard

Wievielter ist eigentlich Österreich geworden bei dieser WM? ;-)

Psst! WM ist ein Rabaeh-Wort - nicht das jetzt dieser Thread eliminiert wird.

Wenigstens duerfen die Alpenkicker bei der naechsten kontinentalen Veranstalung[1] mitmachen und drei Mal spielen. Dann heisst es sowieso Bahbah (oder BaBa?).

man liest sich
Wilhelm

[1] falls EM auch scon auf der Blacklist steht. :-)

[Thomas Mell]

Hallo Thomas,

Aber wieso eigentlich 0.3?
Es gibt zu 1.0 ein RELAX NG (compact)-Schema, vielleicht hilft dir das?

Weil 0.3 nun mal existiert ;-)) Ein Validator sollte schon alle gängigen Versionen unterstützen.
Für 0.3 gibt es auch ein Schema; Müll ist da noch ein Kompliment...

Ja, z.B. mit:
<xs:any processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
(was <xs:any namespace="##any" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> entspricht: ##any = Any well-formed XML from any namespace (default))

Super, genau das habe ich gesucht, vielen Dank.

Meinst du wirklich ein Schema schreiben zu wollen?
Wäre es nicht einfacher in irgendeiner Sprache einen zugeschnittenen Validator zu schreiben?

Das hatte ich schon mal vor geraumer Zeit probiert (da hatten wir noch keinen Schemavalidator). Das war wirklich grausig, für jede Version die Regeln per Programmcode abzufragen - ein Faß ohne Boden... Ein Schema hat nun mal den großen Vorteil der Datentypen, das müsste man alles nachbilden.

Regel wie: "atom:feed elements MUST contain one or more atom:author elements, unless all of the atom:feed element's child atom:entry elements contain at least one atom:author element." sind grausig (wenn nicht unmöglich bei Atom) in Schema umzusetzen.

Das ist noch harmlos, da gibt es bei anderen Versionen noch viel schlimmere Sachen (die ganze RSS/Feed-Geschichte ist ein echtes Frickelwerk).

Ich werde die Sache mit einen "weichen" Schema mit nachgeschalteten Programmcode erledigen (DOM).
Mit <xs:choice maxOccurs="unbounded"> hat man die Möglichkeit das mehrfache Vorkommen von Elementen, und das in beliebiger Reihenfolge, zuzulassen.
Die Sache hat aber den Nachteil das es keine muß-Elemente mehr gibt und jedes Element fehlen oder mehrfach vorkommen darf (aber min. ein Element muß vorhanden sein).
Diese Einschränkungen kann man ganz einfach mit DOM abfragen (es geht ja nur um "wie oft vorhanden"). DOM wird eh benötigt, siehe Dein Beispiel.
Somit würde sich der Programmieraufwand auf ein Minimum beschränken, den 0/8/15-Plunder kann ein Schema besser ;-)

Grüße
Thomas

[Tim Tepaße]

Hallo Thomas,

Gibt es ne Möglichkeit solche Namensräume im Schema zuzulassen, sozusagen "alles mit fremden Namensraum" ?
<xs:any processContents="lax" minOccurs="0" maxOccurs="unbounded"/>

Wobei eine Namespace-Restriktion mit ##other wohl angebracht wäre, sonst würde wohl das hier als richtig validiert, wenn ich das richtig verstehe:

<atom:entry>  
  <atom:feed>  
    ...  
  </atom:feed>  
</atom:entry>

... was ja nun das Konzept der Validierung von Atom ad absurdum führen würde. ;)

Tim

[Thomas J.S.]

Hallo Tim,

Gibt es ne Möglichkeit solche Namensräume im Schema zuzulassen, sozusagen "alles mit fremden Namensraum" ?
<xs:any processContents="lax" minOccurs="0" maxOccurs="unbounded"/>

Wobei eine Namespace-Restriktion mit ##other wohl angebracht wäre, [...]

Ja, das ist korrekt.

... was ja nun das Konzept der Validierung von Atom ad absurdum führen würde. ;)

Welches Konzept der Validierung denn??? ;-)
Ich bin wirklich erstaunt gewesen, dass Atom so ein "wirft doch alles hinein und rühre kräftig daran" Prinzip für die innere Struktur hat. Ich habe die Entwicklung dabei nicht verfolgt, aber ich frage mich, warum man nicht eine vernünfige Schema genommen hat.

Grüße
Thomas

[Tim Tepaße]

Hallo Thomas,

Ich bin wirklich erstaunt gewesen, dass Atom so ein "wirft doch alles hinein und rühre kräftig daran" Prinzip für die innere Struktur hat. Ich habe die Entwicklung dabei nicht verfolgt, aber ich frage mich, warum man nicht eine vernünfige Schema genommen hat.

Die Frage ist auch, wofür man denn mehr bzw. festere innere Struktur braucht. Eigentlich gar nicht. Eine Reihenfolge der Einträge? Lohnt sich nicht. Erstens sortieren die meisten Aggregatoren eh nach Datum, wie man schon bei dem missglückten <items>rdf:Seq von RSS 1.0 gesehen hat, das kaum einer im Sinne des Erfinders, nämlich als signifikante Sequenz, ausgewertet hat. Und zweitens müsste dann die ganze Reihenfolge des Feeds umsortiert werden, wenn ein Eintrag im Feed geupdatet wird, aber dieselbe ID behält.

Und was gibt es sonst für notwendige festere Strukturen in einem Feed? Nimmt man das als hierarchische Datenstruktur im Sinne des DOMs wahr, eigentlich weniger. Ein Feed besteht aus ein paar Metadaten und einer Reihe von Einträgen. Ein Eintrag besteht aus Metadaten und Content, der eventuell noch verschachtelt ist. Mehr ist da ja im Prinzip nicht. Alles andere wäre nur feste Struktur um der geordneteren Struktur willens. Gibt es ja schon teilweise, die Metadaten in einem Feed müssen vor den Einträgen kommen.

Aber sonst? Letztendlich braucht Validierung der Struktur da ja nur die Eltern-Kind-Beziehungen, die Kardinalität, die Existenz von Erforderlichen Elementen und die Datentypen zu überprüfen. Was braucht man da mehr, das nur den Autor in ein Korsett sperren würde?

Tim

[Thomas J.S.]

Hallo Tim,

Ich bin wirklich erstaunt gewesen, dass Atom so ein "wirft doch alles hinein und rühre kräftig daran" Prinzip für die innere Struktur hat. Ich habe die Entwicklung dabei nicht verfolgt, aber ich frage mich, warum man nicht eine vernünfige Schema genommen hat.

Die Frage ist auch, wofür man denn mehr bzw. festere innere Struktur braucht. Eigentlich gar nicht. Eine Reihenfolge der Einträge? Lohnt sich nicht. Erstens sortieren die meisten Aggregatoren eh nach Datum, [...]

Und was gibt es sonst für notwendige festere Strukturen in einem Feed? [...] Gibt es ja schon teilweise, die Metadaten in einem Feed müssen vor den Einträgen kommen.

Es geht nicht darum ob und wenn wie atom:entry-Einträge sortiert werden sollen. Sondern darum welche Reihenfolge der Elemente überhaupt haben kann.
Lese man http://www.atompub.org/rfc4287.html#element.entry: "This specification assigns no significance to the order of appearance of the child elements of atom:entry."
Dagegen wird bei atom:feed folgendes gesagt "Its element children consist of metadata elements followed by zero or more atom:entry child elements."

Die zweite Aussage impliziert doch, dass im Feed erst die Metadaten dann die Einträge stehen, der erste dagegen sagt, dass es (innerhalb vom atom:entry) vollkommen egal ist, in welcher Reihnefolge die Elemente stehen. Das ist schon mal inkonsequent, vor allem wenn man bedenkt, dass ein atom:entry ebenfalls als top-level-Element stehen kann.

Eine weitere Inkonsequenz in meinen Augen ist atom:id, von der gesagt wird "The "atom:id" element conveys a permanent, universally unique identifier for an entry or feed." und an einer anderen Stelle heisst es "If multiple atom:entry elements with the same atom:id value appear in an Atom Feed Document, ...".
Wir können - müssen aber nicht - darüber diskutieren, dass es sinvoll ist (in verbindung mit atom:update) etc. das ändert aber nichts an der Inkonsequenz der Formulierungen (etweder ist etwas "universally unique" oder nicht, ein bisschen schwanger geht auch nicht)

Aber sonst? Letztendlich braucht Validierung der Struktur da ja nur die Eltern-Kind-Beziehungen, die Kardinalität, die Existenz von Erforderlichen Elementen und die Datentypen zu überprüfen. Was braucht man da mehr, das nur den Autor in ein Korsett sperren würde?

Das hört sich so an, als ob es viele viele Leute gäbe die ihre Feeds per Hand schreiben. Ich zweifle daran. Beim Schreiben eines Feed-Generators wäre es durchaus sinnvol zu sagen, welche Reihenfolge Elemente haben müssen. Eine Struktur wie:
autor
content
autor
id
category
autor
category
contibutor
autor
category ... etc.

finde ich nicht wirklich sinnvoll.

Grüße
Thomas

[Tim Tepaße]

Hallo Thomas,

Es geht nicht darum ob und wenn wie atom:entry-Einträge sortiert werden sollen. Sondern darum welche Reihenfolge der Elemente überhaupt haben kann.

Ja, ich hab das schon verstanden. Aber ich sehe immer noch keinen Grund ausser Validierung mit XML Schema, der dafür spricht, überhaupt eine Reihenfolge festzulegen.

Die zweite Aussage impliziert doch, dass im Feed erst die Metadaten dann die Einträge stehen, der erste dagegen sagt, dass es (innerhalb vom atom:entry) vollkommen egal ist, in welcher Reihnefolge die Elemente stehen. Das ist schon mal inkonsequent, vor allem wenn man bedenkt, dass ein atom:entry ebenfalls als top-level-Element stehen kann.

Da bin ich Deiner Meinung, das ist inkonsequent.

Eine weitere Inkonsequenz in meinen Augen ist atom:id, von der gesagt wird "The "atom:id" element conveys a permanent, universally unique identifier for an entry or feed." und an einer anderen Stelle heisst es "If multiple atom:entry elements with the same atom:id value appear in an Atom Feed Document, ...".

Nun ja, die globale Eindeutigkeit ist hier eher darauf ausgerichtet, auch beim Vermischen von entrys aus unterschiedlichen Quellen Einträge eindeutig identifizieren zu können. Sehr praktisch, wenn ein Eintrag in unterschiedlichen Feeds in einem Aggregator auftaucht. Eindeutigkeit innerhalb des Feeds im Sinne einer XML ID in einem XML-Dokument ist da eher weniger gemeint; schließlich ist ein Feed ein sich permanent veränderndes Dokument. U.a. deswegen ist die ID ja auch kein Attribut mit dem Datentyp ID.

Wir können - müssen aber nicht - darüber diskutieren, dass es sinvoll ist (in verbindung mit atom:update) etc.

Und für die Identifizierung eines doppelten Eintrages gibt es ja diesen Extra-Mechanismus.

Das hört sich so an, als ob es viele viele Leute gäbe die ihre Feeds per Hand schreiben. Ich zweifle daran.

Jain. Aber es gibt durchaus Leute, die die Templates oder PHP-Dokumente für ihre Feeds per Hand basteln. ;)

Beim Schreiben eines Feed-Generators wäre es durchaus sinnvol zu sagen, welche Reihenfolge Elemente haben müssen.

Ehrliche Frage: Wieso? Aus menschlicher, organisatorischer Sicht des Quellcodes ist es sinnvoll, klar. Aber wieso sollte eine Spezifikation dafür eine global einheitliche Reihenfolge festlegen müssen? Welchen Vorteil zieht man daraus?

finde ich nicht wirklich sinnvoll.

Ich gehe die Frage aus anderer Richtung an: Jede Einschränkung in Rigidität sollte schon Vorteile aufweisen, ehe ich sie als sinnvoll erachte. Insofern lautet meine Frage: Welcher Vorteil bestände darin, wenn ich Metadaten-Elemente nun plötzlich ordnen müsste? Es ist ja letztendlich nur eine Serialisierung einer Datenstruktur, kein Dokument. Der einzige Vorteil, der mir einfällt, ist Freundlichkeit gegenüber den Beschränkungen von XML Schema. Gibt es irgendwas anderes, sinnvolles, was Du siehst, ich aber nicht?

Tim

[Tim Tepaße]

Hallo Thomas,

Momentan sitze ich an den Specs von Atom 0.3 http://www.atomenabled.org/developers/syndication/#requiredFeedElements.

Ähm. Das ist nicht die Spezifikation von Atom 0.3. Das ist eine lockere Beschreibung von Atom 1.0. Man gucke sich nur den Namensraum an. Der damalige Wiki-Snapshot, der dann als Atom 0.3 bei atomenabled.org ebenso locker aufgeschrieben wurde bis man ein IETF-Ergebnis hatte, liegt hier:
http://www.mnot.net/drafts/draft-nottingham-atom-format-02.html

Ich bin aber wie Thomas J.S. der Meinung, dass Du das lassen solltest. Atom 0.3 wird zwar noch benutzt und Entwickler von Aggregatoren müssen diesen noch implementieren. Dennoch waren die Wiki-Snapshots niemals als „Ergebnis“ (analog zu HTML 2.0, 3.2, 4.0) gedacht, sondern nur als eine Zwischenstufe der Entwicklung und der Diskussion. Wer Atom 0.3 anbietet sollte klar sein, dass das nur eine Zwischenstufe und nicht das Endergebnis ist. Atom gibt es bislang de jure nicht in  verschiedenen Versionen, Atom heisst RFC 4287.

Von einem Validator würde ich erwarten, dass er das anmerkt. Er kann zusätzlich auch gerne 0.3 validieren, wenn er nur sagt: „Du solltest unbedingt auf Atom 1.0 wechseln, schließlich ist das der Standard, von Atom 0.3 findet kaum noch einer die Spezifikation im Netz.“ Man mag von Feedvalidator halten, was man meint, aber da macht er das richtig.

Vor allem bedenke die Arbeit. Nach derselben Logik müsstest Du dann die Wiki-Snapshots 0.1, 0.2 und den informellen 0.2.1 unterstützen, schließlich flogen oder fliegen davon Feeds im Netz rum. Und die elf Internet Drafts, die veröffentlicht wurden, nachdem sich die Diskussion auf die Mailingliste verlagert hatte. Ich möchte noch mal betonen: Drafts. Entwürfe. Kein fertiges Endprodukt.

... und das auch noch in beliebiger Reihenfolge (jedenfalls sehe ich keinen Hinweis auf eine feste Folge).

Ich bin da ja eher Laie, aber kann das sein, dass XML Schema durch sein sparsames Angebot von Kompositoren in Model Groups ein dokumentzentrisches Bild von XML fordert denn ein eher in Datenstrukturen denkendes?

So wie das aussieht werde ich dafür wohl ein "weiches" Schema machen müssen und anschließend mit DOM per Hand nachbessern müssen.

Den Zugriff übers DOM halte ich bei all den verschiedenen Constrains für geschickter. Diese sind nämlich nicht in den diversen Schematasprachen ausdrückbar. Das nicht normative RELAX NG Schema hat zwar ein paar Schematron-Regeln, aber die decken ja auch nur eine kleine Teilmenge des Textes ab.

Tim

[Thomas Mell]

Hi Tim,

Ähm. Das ist nicht die Spezifikation von Atom 0.3.

Ich weiß, bin ein copy & paste - Legastheniker ;-))

Ich bin aber wie Thomas J.S. der Meinung, dass Du das lassen solltest. Atom 0.3 wird zwar noch benutzt und Entwickler von Aggregatoren müssen diesen noch implementieren...

Eben genau des wegen muss Validome das unterstützen.

Von einem Validator würde ich erwarten, dass er das anmerkt. Er kann zusätzlich auch gerne 0.3 validieren, wenn er nur sagt: „Du solltest unbedingt auf Atom 1.0 wechseln, schließlich ist das der Standard, von Atom 0.3 findet kaum noch einer die Spezifikation im Netz.“ Man mag von Feedvalidator halten, was man meint, aber da macht er das richtig.

Natürlich könnten wir das machen, nur ist es nicht unsere Aufgabe den User auf so was hinzuweisen. Wenn jemand HTML 3 bei uns validiert weisen wir ihn auch nicht darauf hin das er besser 4.01 benutzen soll (oder XHTML ?!).

Vor allem bedenke die Arbeit. Nach derselben Logik müsstest Du dann die Wiki-Snapshots 0.1, 0.2 und den informellen 0.2.1 unterstützen

Nein, genau so wenig wie 0.92 oder 0.93. Wir werden nur jene Versionen unterstützen die entweder in Massen verwendet werden, oder wo es finale Versionen gibt (natürlich auch Atom 1.0).

Ich bin da ja eher Laie, aber kann das sein, dass XML Schema durch sein sparsames Angebot von Kompositoren in Model Groups ein dokumentzentrisches Bild von XML fordert denn ein eher in Datenstrukturen denkendes?

Nun, es ist und bleibt XML mit bestimmten Regeln. Wie man diese Regeln am praktischsten überprüft ist eine andere Sache. Nach Tagelangen Versuchen habe ich aber eine Lösung gefunden.
Ein Schema wird auf jeden Fall verwendet, schon um die 0/8/15-Fehler zu finden (Syntax, Verschachtelungsfehler, Attributfehler usw.).
Weiterhin hat ein Schema den großen Vorteil Daten (Attribut- und Elementwerte) auf bestimmte Typen zu überprüfen (URI, Date, Time usw.).
Alle weitergehenden Regeln, welche nicht mit einen Schema ausgedrückt werden können, werden mit DOM überprüft.
Das ist für mich der beste Kompromiss zwischen Präzision und Arbeitsaufwand.

Grüße
Thomas

[Tim Tepaße]

Hallo Thomas,

Natürlich könnten wir das machen, nur ist es nicht unsere Aufgabe den User auf so was hinzuweisen. Wenn jemand HTML 3 bei uns validiert weisen wir ihn auch nicht darauf hin das er besser 4.01 benutzen soll (oder XHTML ?!).

Genau das solltet ihr aber tun. HTML 3.0 ist zum einen ein abgelaufener Entwurf einer Spezifikation, die nur zu Diskussion gedacht war. Zum anderen definiert dieser Entwurf Elemente, die niemals in Browsern umgesetzt wurden wie <math> oder <fig>.

Die Leute kommen zu einem Validator nicht nur, um eine begrenzte Richtigkeit nach einer DTD oder einem Schema zu überprüfen. Sie kommen mit der umfassenderen Frage zu einem Validator „Ist das richtig, was ich hier gemacht habe?“. HTML 3 zu verwenden ist im Kontext des Webs nicht richtig. Ein Validator sollte das sagen. Er muss keine Meinung haben, was nun besser ist – er muss einfach nur darauf hinweis, dass sich der Validierende mit der Entscheidung selbst in den Fuß schießen könnte.

Nein, genau so wenig wie 0.92 oder 0.93. Wir werden nur jene Versionen unterstützen die entweder in Massen verwendet werden, oder wo es finale Versionen gibt (natürlich auch Atom 1.0).

Ich halte das Wort von Versionen hier immer noch für falsch. Das eine war ein Snapshot, der aktuelle Diskussionen im Wiki zusammenfasste. Eine lockere Momentaufnahme in einer fliessenden Diskussion. Das andere ist die einzige Version. Wenn ein neuer RFC veröffentlicht wird würde ich erst von einer neuen Version sprechen. Weil eine Version für mich den „Siegel“ des Standards braucht.

Guck mal in die Zukunft: In fünf Jahren will jemand einen Atom-Parser implementieren. Der hat keine Ahnung davon, dass es mal Snapshots gab. Alles, wonach der sich richten wird ist der RFC, der Atom 1.0 beschreibt. Weil das Atom ist. Und er hat jegliches Recht dazu, keiner kann von ihm verlangen, dass er irgendwelche nicht normativen Momentausnahmen aus der Entwicklungszeit unterstützen muss. Leute, die dann immer noch auf die Momentaufnahme Atom 0.3 setzen, sind dann doof dran. Weil ihnen niemand gesagt hat, dass das nicht so richtig ist, was sie da tun.

(Ach ja, da Du von RSS 0.92, 0.93 redest: Die werden durchaus auch noch verwendet.)

Tim

[Thomas Mell]

Hi Tim,

Genau das solltet ihr aber tun. HTML 3.0 ist zum einen ein abgelaufener Entwurf einer Spezifikation, die nur zu Diskussion gedacht war. Zum anderen definiert dieser Entwurf Elemente, die niemals in Browsern umgesetzt wurden wie <math> oder <fig>.

HTML 3.0 war doch nur ein Beispiel, sollen wir dann bei 4.01 sagen "Benutze das, ist ja Klasse", oder "benutze XHTML, ist auch Klasse"; und schon geht die alte Leier los ob XHTML "besser" ist...
Wir wollen nicht beraten und belehren, das überlassen wir anderen (z. B. SELFHTML ?) Wir sehen unsere Aufgabe darin, Dokumente anhand von Regeln (Empfehlungen, Specs oder sonst was), ob normativ oder nicht, zu überprüfen; nicht mehr aber auch nicht weniger.

Die Leute kommen zu einem Validator nicht nur, um eine begrenzte Richtigkeit nach einer DTD oder einem Schema zu überprüfen. Sie kommen mit der umfassenderen Frage zu einem Validator „Ist das richtig, was ich hier gemacht habe?“.

Wie kommst Du zu der Annahme ? Unsere Erfahrung sagt da aber ganz was anderes. Es kommt äußerst selten vor das jemand validiert und dann zum Schluss kommt das ein anderer Dokumententyp "besser" ist. User die Validieren sind fast alle "weiter" als der dau (wir haben mehr Firefox als IE Besucher), und der dau validiert nicht da eh nix kapiert bzw. ganz andere Probleme hat als den Dokumententyp.

Ich halte das Wort von Versionen hier immer noch für falsch.

Wir können jetzt gerne eine Sinnfreie Diskussion anzetteln was man unter "Version" zu verstehen hat ;-)
0.9 ist für mich eine andere Version als 0.91, 0.8.15 oder 47.11 - schnurzpiepegal wie sie entstanden ist.
Weiterhin ist "Version" ganz was anderes als "Standard".

Guck mal in die Zukunft: In fünf Jahren will jemand einen Atom-Parser implementieren. Der hat keine Ahnung davon, dass es mal Snapshots gab. Alles, wonach der sich richten wird ist der RFC, der Atom 1.0 beschreibt Weil das Atom ist...

...oder Atom 2.8, oder, oder...

Und er hat jegliches Recht dazu, keiner kann von ihm verlangen, dass er irgendwelche nicht normativen Momentausnahmen aus der Entwicklungszeit unterstützen muss. Leute, die dann immer noch auf die Momentaufnahme Atom 0.3 setzen, sind dann doof dran. Weil ihnen niemand gesagt hat, dass das nicht so richtig ist, was sie da tun.

Hmmm, dann empfehlen wir Ihn heute Atom 1.0; wenn dann in 14 Monaten eine 1.1 oder 2.0 erscheint, müssen wir wieder nachbessern und Texte ändern, und das ganze in 3 Sprachen. Da sich dann solche Hinweise durch das ganze Projekt ziehen, müssten wir  regelmäßig an 100 Stellen nachbessern - och nö.
Ich verstehe ja dein Anliegen, nur solche Wünsche nach erweiterten Hinweisen haben wir massenhaft (denke nur mal die vielen denkbaren Hinweise zum IE). Das Problem ist dabei die Softwarepflege, da solche Hinweise schnell überholt sind, bzw. neue hinzukommen (IE 6 -> IE 7).
Nichts würde ich lieber machen als das, aber wir haben so viele Projekte auf Halde liegen (z.B. ein CSS-Validator oder lokale Validatoren) das wir für so etwas einfach keine Zeit haben; wir sind personell schlicht unterbesetzt.

(Ach ja, da Du von RSS 0.92, 0.93 redest: Die werden durchaus auch noch verwendet.)

Ist zwar kaum verbreitet, aber vielleicht unterstützen wir die auch ;-)

Grüße
Thomas

[Tim Tepaße]

Hallo Thomas,

HTML 3.0 war doch nur ein Beispiel, sollen wir dann bei 4.01 sagen "Benutze das, ist ja Klasse", oder "benutze XHTML, ist auch Klasse"; und schon geht die alte Leier los ob XHTML "besser" ist...

Nein, darum geht es mir gar nicht. Da sollte keine Warnung aufpoppen, da ist es wurst. Ebensowenig bei HTML 2, HTML 3.2, XHTML 1.1, XHTML Basic oder von mir aus auch ISO-HTML. Das sind ja alles akzeptierte Standards, aktuell und zu ihrer Zeit.

Es geht mir darum, dass einfach nur eine Warnung aufpoppt, wenn eine nicht akzeptierte, nicht offizielle Version (jetzt in Deiner Interpretation) verwendet wird. Ungefähr so, in natürlich anderer Wortwahl:

„Warnung: Du verwendest eine Variante von HTML, die niemals ein offizieller
  Standard war oder gar in Browsern implementiert wurde. Du könntest damit auf
  Probleme stoßen, wenn Du auf Funktionalität im tatsächlichen Web hoffst. Wenn
  Du Dir aber sicher bist, dass Du wirklich HTML 3.0 verwenden willst, dann lass
  Dich davon nicht beirren.“

Oder meinetwegen auch nicht „Warnung“ sondern „Hinweis“. Und danach kommen dann die eventuellen Fehler/Warnungen wie üblich. Es ist einfach nur ein Hinweis, dass man sich selber in den Fuß schießen könnte, wenn man wirklich hofft, dass das so klappt. Und ansonsten geht's weiter wie normal.

„Ist das richtig, was ich hier gemacht habe?“.
Wie kommst Du zu der Annahme ? Unsere Erfahrung sagt da aber ganz was anderes.

Anhand der Beobachtung hier im Forum. Leute, die zum Validieren geschickt werden oder mit Fragen vom Validieren kommen erwecken zu einem sehr großen Anteil den Eindruck, dass es ihnen bewusst ist, dass ein Validator nur nach DTD oder Schema validert – und da Lücken haben kann. Die gehen dahin, um zu gucken, ob das richtig ist, was sie tun. Richtigkeit im Sinne des Standards und des tatsächlichen Webs, nicht im begrenzten technischen Sinne der Validität gegen durch DTDs/Schemata ausdrückbaren Regeln. Schon allein, weil sie nichts davon wissen. Sie wollen nur HTML schreiben und das richtig machen. Und ich würde sagen, dass ist der größere Anteil eurer Zielgruppe.

User die Validieren sind fast alle "weiter" als der dau

Ja, aber sind sie so weit, dass sie wissen, dass sie beim W3C Validator nur eine begrenzte SGML-Validität gegenüber DTDs bekommen und nicht mehr, wenn man ihnen überall einredet, dass das Ding Fehler aufspürt?

Das Konzept des Validators hat sich meiner Meinung da verändert, vom technischen Sinne zu „Richtigkeit“. Einen Validator, der versucht etwas mehr „Richtigkeit“ zu implementieren (und diese gut kommuniziert) halte ich da für besser als einen Validator, der das nicht tut.

Hmmm, dann empfehlen wir Ihn heute Atom 1.0; wenn dann in 14 Monaten eine 1.1 oder 2.0 erscheint ...

Nun ja, technische Standards sind immer ein Hase-und-Igel-Rennen. Wobei: Die Entwicklung geht ja doch sehr viel langsamer. Ich rechne nicht vor fünf Jahren mit einer Errata-Version oder gar einer neuen Version von Atom, zehn Jahre halte  ich bei letzterem für Wahrscheinlicher.

müssen wir wieder nachbessern und Texte ändern, und das ganze in 3 Sprachen. Da sich dann solche Hinweise durch das ganze Projekt ziehen, müssten wir regelmäßig an 100 Stellen nachbessern - och nö.

Hm? Ihr habt die Meldungen nicht vom Code abgekoppelt? Das wundert mich jetzt wirklich.

Ich verstehe ja dein Anliegen, nur solche Wünsche nach erweiterten Hinweisen haben wir massenhaft (denke nur mal die vielen denkbaren Hinweise zum IE). Das Problem ist dabei die Softwarepflege, da solche Hinweise schnell überholt sind, bzw. neue hinzukommen (IE 6 -> IE 7).

Ja, aber das verlange ich ja gar nicht. Mir geht es einfach nur um ein paar Warnungen bezüglich veralteter oder gar nie benutzter Versionen. Ich finde das keinen großen Aufwand, schließlich sind diese alle einfach zu erkennen. Im Falle von Atom < 1.0 wäre das einfach nur eine Überprüfung des Namensraumes, in dem sich die Elemente befinden.

(Ach ja, da Du von RSS 0.92, 0.93 redest: Die werden durchaus auch noch verwendet.)
Ist zwar kaum verbreitet, aber vielleicht unterstützen wir die auch ;-)

Psst. Ich könnte noch mindestens fünf weitere Formate für Feeds aufzählen. ;)

Tim

[Tim Tepaße]

Hallo Gunnar,

Leute, die zum Validieren geschickt werden oder mit Fragen vom Validieren kommen erwecken zu einem sehr großen Anteil den Eindruck, dass es ihnen bewusst ist, dass ein Validator nur nach DTD oder Schema validert ...

Das sollte natürlich „... erwecken zu einem sehr großen Anteil den Eindruck, dass es ihnen _nicht_ bewusst ist ...“ heißen. Tipp in Zukunft einfach langsamer. ;)

Tim

[Thomas Mell]

Hi Tim,

...Oder meinetwegen auch nicht „Warnung“ sondern „Hinweis“. Und danach kommen dann die eventuellen Fehler/Warnungen wie üblich. Es ist einfach nur ein Hinweis, dass man sich selber in den Fuß schießen könnte, wenn man wirklich hofft, dass das so klappt. Und ansonsten geht's weiter wie normal.

Im Bereich [X]HTML können wir uns sparen da alle Versionen vor 4.01 so gut wie nie validiert werden (sagt unser Log), und wenn, dann handelt es sich um Fehlermeldungen eines Servers ;-)

Wie kommst Du zu der Annahme ? Unsere Erfahrung sagt da aber ganz was anderes.

Anhand der Beobachtung hier im Forum. Leute, die zum Validieren geschickt werden oder mit Fragen vom Validieren kommen erwecken zu einem sehr großen Anteil den Eindruck, dass es ihnen bewusst ist, dass ein Validator nur nach DTD oder Schema validert – und da Lücken haben kann. Die gehen dahin, um zu gucken, ob das richtig ist, was sie tun. Richtigkeit im Sinne des Standards und des tatsächlichen Webs, nicht im begrenzten technischen Sinne der Validität gegen durch DTDs/Schemata ausdrückbaren Regeln. Schon allein, weil sie nichts davon wissen. Sie wollen nur HTML schreiben und das richtig machen. Und ich würde sagen, dass ist der größere Anteil eurer Zielgruppe.

Ging die Diskussion nicht um den "richtigen" Dokumententyp ? Was hat das jetzt mit der Arbeitsweise eines Validators zu tun ?
Im übrigen validiert Validome nicht nur nach DTD/Schema. Wir überprüfen heuristisch Unmengen von weiteren Regeln (Beispiel Anker und bestimmte Attributwert) um den Spezifikationen (oder eher Empfehlungen) möglichst nahe zu kommen.

User die Validieren sind fast alle "weiter" als der dau

Ja, aber sind sie so weit, dass sie wissen, dass sie beim W3C Validator nur eine begrenzte SGML-Validität gegenüber DTDs bekommen und nicht mehr, wenn man ihnen überall einredet, dass das Ding Fehler aufspürt?

Das Ding spürt ja Fehler auf, nur leider einen Bruchteil der möglichen ;-) Deswegen ist ja Validome schlechter, der Zeigt Fehler an welche der W3C-Validator nicht anzeigt; somit Fehlerhaft ;-))
Ach weißt Du, man wird niemals die Menschheit davon überzeugen können das der W3C-Validator eine Lachnummer ist, ist ja schließlich vom tollen W3C...
Entweder die User merken das von selber oder eben nicht, ändern können wir das eh nicht außer weiterzuarbeiten.
Schau mal, SELFHTML gab es vor dem W3C (und wird es hoffentlich auch noch danach geben) . Die Doku ist in jeder Hinsicht besser und umfangreicher als dieses durch und durch fehlerhafte W3C-Theoriegeschwür, da aus der Praxis gewachsen; trotzdem ist das W3C „besser“.
Mal ehrlich, wie viele Menschen kennst Du die auch nur die ersten 30 Sätze einer beliebigen W3C-Empfehlung nach dem 3. Durchlesen „wirklich“ kapieren ? – ich nicht einen.

Das Konzept des Validators hat sich meiner Meinung da verändert, vom technischen Sinne zu „Richtigkeit“. Einen Validator, der versucht etwas mehr „Richtigkeit“ zu implementieren (und diese gut kommuniziert) halte ich da für besser als einen Validator, der das nicht tut.

Stimmt, und genau daran arbeiten wir.

Hm? Ihr habt die Meldungen nicht vom Code abgekoppelt? Das wundert mich jetzt wirklich.

Natürlich sind die abgekoppelt (ebenso wie das Design und die Parser). Es ist aber nicht nur mit den Texten getan, diese müssen auch nach bestimmten Regeln ausgegeben werden (Programmieren).

Ja, aber das verlange ich ja gar nicht. Mir geht es einfach nur um ein paar Warnungen bezüglich veralteter oder gar nie benutzter Versionen. Ich finde das keinen großen Aufwand, schließlich sind diese alle einfach zu erkennen. Im Falle von Atom < 1.0 wäre das einfach nur eine Überprüfung des Namensraumes, in dem sich die Elemente befinden.

Es geht noch einfacher, der User muß eh in der Oberfläche die Version manuell auswählen (eine automatische Erkennung wird es nicht geben).
Ok, bei Atom 0.3 werde ich mal machen...

(Ach ja, da Du von RSS 0.92, 0.93 redest: Die werden durchaus auch noch verwendet.)
Ist zwar kaum verbreitet, aber vielleicht unterstützen wir die auch ;-)

Psst. Ich könnte noch mindestens fünf weitere Formate für Feeds aufzählen. ;)

*g*, immer her damit ;-)

Grüße
Thomas

[Tim Tepaße]

Hallo Thomas,

Ging die Diskussion nicht um den "richtigen" Dokumententyp ?

Jain. Ich würde sagen, es ist allgemein akzeptiert, dass es „richtiger“ ist, Atom 1.0 denn Atom 0.3 (oder 0.2 oder 0.1) zu verwenden. Ebenso, wie es „richtiger“ ist, HTML 4.01 oder XHTML 1.0 oder HTML 3.2 oder HTML 2.0 denn HTML 3.0 zu verwenden. Ich meine schon, ein Validator sollte dieses ausdrücken. Aber er muss oder sollte keine Meinung zu Strict vs. Transitional oder HTML vs. XHTML haben.

Psst. Ich könnte noch mindestens fünf weitere Formate für Feeds aufzählen. ;)
*g*, immer her damit ;-)

Wenn Du Spaß daran hast, hier mal eine viel zu vollständige Liste:

Aus der Abteilung „Intellektuelle Vorläufer“:
• Das von Ramanathan V. Guha bei Apple entwickelte Meta Content Framework ist eher ein RDF-Vorläufer, Dave Winers Userland hat aber damals rumexperimentiert, als MCF noch nicht in XML notiert wurde.
• Microsofts Channel Definition Format für den Active Desktop – erinnert sich noch jemand? Hat Userland auch mit rumexperimentiert.

Aus der Abteilung „Ganz vorsichtig den Fuss ins Wasser stecken“:
• Dave Winer wirft ein eigenes scriptingNews-XML-Format für sein eigenes Weblog Scripting News ins Web. Es ist aber keine Spec oder kein Beispiel dafür überliefert.
• Dave Winer veröffentlich scriptingNews 2.0b1.

Aus der Abteilung „RSS – von Netscape über Userland bis Harvard“:
• Netscape veröffentlicht das RDF-basierte RSS 0.9, das in einer größeren RDF-Anwendung in der  Zukunft aufgehen soll.
• Netscape gibt RDF auf und veröffentlicht RSS 0.91 als reines XML-Format.
• Dave Winer nimmt Netscapes RSS 0.91, erstellt davon eine eigene, aber andere Version und veröffentlicht das als RSS 0.91.
• Leute, die das RDF in RSS vermissen, veröffentlichen RSS 1.0
• RSS 0.92
• RSS 0.93 – ist allerdings ein zurückgezogener Entwurf.
• RSS 0.94 – ein zurückgezogener Entwurf, für den keine Spezifikation mehr existiert. Wenn man über ein description-Element in einem Feed stolpert, dass ein type-Attribut hat, weiss man: Aha, da hat jemand mal was von RSS 0.94 gelesen.
• RSS 2.0 (mit sechs Revisionen)

Aus der Abteilung „Hey, wir wollen das Rad neu erfinden“:
• KlipFolio entwirft ein Format namens KlipFood, das aussieht wie billigstes RSS mit einem anderen Root-Element. Scheinen sie aber inzwischen aufgegeben haben.

Aus der Abteilung „Lasst Namensräume blühen“:
• RSS 2.0 Feeds mit content:encoded werden Normalität
• RSS 2.0 Feeds mit Dublin-Core-Metadaten werden Normalität
• RSS 2.0 Feeds mit xhtml:body werden zumindest mal ausprobiert
• RSS 2.0 Feeds mit atom:content werden angedacht

Aus der Abteilung „Gnihihi“:
• Aaron Swartz' RSS 3.0 – ein Format im Stil von RFC 822x
• Epistula Syndication Format (ESF) – wieder kein XML
• Super Simple Syndication (SSS) – noch simpler geht's eigentlich nicht.

Aus der Abteilung „Einsame Weltverbesserer“:
• RSS 1.1 – ein nicht offizielles Bugfix-Release für RSS 1.0
• RSS 3 Lite & Co – ein Versuch einer einzigen Person, eine neue, auf RSS 2.0 aufbauende Spezifikation zu basteln, mit ganz, ganz schwieriger Sprache. Es gab wohl kaum Rückmeldung, aber eine anwaltliche Meldung von obigen Aaron Swartz, also ist das ganze eingeschlafen.

Aus der Abteilung „Ich hab meine Feeds am liebsten mitten im HTML“:
• Site Summaries in XHTML
• HTML Syndication Format 1.0, Draft 1
• hAtom

Aus der atomaren Abteilung:
• Atom (nEcho) 0.1
• Atom 0.2
• Atom 0.3
• Atom 1.0 (RFC 4287)

Bestimmt habe ich jetzt irgendeine beknackte Feed-Spezifikation vergessen. ;)

Tim