Was ist bei der Gestaltung eines XML-Feeds für strukturierte Daten sinnvoll und welche Anti-Patterns gibt es?
Ich hätte gerne Antworten, die XML-Struktur und Inhalt und / oder Transportmechanismen abdecken.
Transportmechanismen
Mit aktuellen Technologien ist FTP / SFTP eine gute Technologie? Gibt es Fälle, in denen es die beste Lösung ist?
Generell bevorzuge ich HTTP-Pull-Feeds, aber welche Schwächen hat HTTP?
Welche anderen Fütterungsmechanismen sollten mit ihren Vor- und Nachteilen in Betracht gezogen werden?
XML-Strukturinhalt
Wenn es keine geeignete existierende DTD / Schema gibt, welche Praktiken können befolgt werden, um ein gutes XML-Design zu erstellen?
Zwei Anti-Muster dafür habe ich bereits in meiner Antwort unten angegeben.
Aber was soll ich tun, wenn ich ein Futtermittel entwerfe? Ich würde gern etwas über Tags und Attribute erfahren, wie relationale Daten (insbesondere Viele-zu-Viele-Beziehungen) in XML usw. vermittelt werden sollten.
Hinweis : Ich habe die Frage komplett umgeschrieben, da selbst mit der gebotenen Prämie nicht viel Liebe gewonnen wurde. (Die alte Version befindet sich im Bearbeitungsverlauf, wenn Sie sie sehen möchten. Diese Version sollte den bereits gegebenen Antworten entsprechen)
Ein guter Feed hat
1) Ein Schema, denn auf diese Weise können Sie es programmatisch überprüfen und Sie wissen, wann es geändert wurde - spart viele Argumente
2) Informiert Sie, wenn es nicht verfügbar ist
3) funktioniert durchgängig
4) Handle stoppt, startet, pausiert, spult elegant zurück
5) Verfügt über einen Testdienst, der alle vorhandenen Feedfunktionen vollständig ausübt
6) Verfügt über einen neuen Feature-Service für die Sandbox-Entwicklung
Realistisch gesehen habe ich nur mit Feeds gearbeitet, die 1 und manchmal 2 liefern, aber wir können träumen.
Ohne eine DTD / ein Schema haben Sie keine Möglichkeit zu wissen, ob ein Feed gültig ist, bis Ihr Code auf ein Problem stößt. Für mich sind also Schemas sehr wichtig, sowohl als XML-Konsument als auch als Produzent.
Auch ein einfaches Schema ist nützlich, um die Elemente zu definieren, wie oft sie vorkommen usw. Ein detailliertes Schema, mit Einschränkungen oder Aufzählungen nach Bedarf, ist noch schöner. Wenn ich diese habe, kann ich die Anzahl der Fehler in der von mir erzeugten XML minimieren, oder ich kann die gesamte Datei validieren, wenn sie an mich gesendet wird, und sie als nicht konform ablehnen. Es ist nur eine übersichtliche Standardmethode für die Validierung von Eingaben.
Es ist eine gute Frage, aber ich weiß nicht, wie weit es weiter geht als Schema gut,! Schema schlecht.
Ich musste Feeds konsumieren, die fehlerhafte Schemas nicht zur Verfügung stellten oder zur Verfügung stellten, und realistischerweise kann man sie nur in namespace-lose Klone umwandeln, was zwar praktikabel, aber riskant ist.
I18N und vor allem Zahlenformate und Datumsstempel sind ein massives Problem. Es empfiehlt sich natürlich, das Format im Dokument zu deklarieren und vorzugsweise die UTC-Zeit anzugeben.
Ich schätze, die einzige andere gute Praxis, die ich vorschlagen kann, ist, wenn mehrere Feeds, die interagieren müssen, nicht versuchen, mit ihnen zu ihren Bedingungen umzugehen, sondern das erste, was Sie tun müssen, ist, sie zu einem Standardobjekt zu deserialisieren wandle sie in ein internes Standardschema um.
Ohne die tatsächlichen Anforderungen zu kennen, ist es schwierig, Empfehlungen für Transportmechanismen oder -stile zu geben. Wenn Sie beispielsweise Pull-basierte Syndikation durchführen, bietet HTTP Funktionen, die beim Caching helfen. Wenn Sie Push-basierte oder Publish / Subscribe-Protokolle wie XMPP verwenden
Für Ihren Feed selbst würde ich empfehlen, eine öffentliche Spezifikation wie Atom einzuhalten (oder vielleicht eine RSS-Variante, wenn Sie möchten). Atom enthält einige der von Ihnen erwähnten Elemente, z. B. das Kodieren von Inhalten und Datumsformaten (in den meisten Fällen ist die Verwendung von UTC am einfachsten und wird dann in die lokale Zeit eines Benutzers zur Anzeige konvertiert). Indem Sie sich an Standardformate halten, können Sie auch Feed-Parser verwenden, die diese Spezifikation unterstützen.
Atom und RSS sind flexibel genug, um es Ihnen zu ermöglichen, eigene XML-Namespaces zu definieren, um Elemente und Attribute hinzuzufügen, die Sie benötigen. Wenn Ihre produzierten Daten nicht auf das Feed- / Erfassungsdatenmodell abgebildet werden, sind sie möglicherweise nicht die beste Lösung für Sie.
Wenn Sie XML, Eltern / Kind-Beziehungen (wobei das Kind nur 1 Elternteil hat) verwenden, können diese leicht als Eltern / Kind-Elemente modelliert werden. Wenn das Kind mehrere Eltern hat, können Sie Referenzen und Attribute verwenden, um Elemente zu verknüpfen.
Ein persönlicher Fehler von mir sind im Moment Zeitstempel ohne Zeitzoneninformationen. Wenn es sich um Feeds aus der ganzen Welt handelt, ist eine Zeit ohne Zeitzone bedeutungslos.
Bearbeiten: Und Feeds, die kein Encoding-Attribut enthalten, oder ein solches einschließen, aber dann respektieren Sie es nicht!
Ich denke MediaRSS ist ein ziemlich gutes Feed-Schema. Ich mag es, weil:
Eine Sache, die ich möchte, dass es nicht ein Tag für willkürliche Parameter ist, die an den Player eines bestimmten Mediums übergeben werden sollen, aber ich denke nicht, dass das wirklich Sinn macht, da der Feed nicht sollte Ich muss nichts über den Spieler wissen. Aber manchmal muss ich nur Params an den Flash-Player übergeben.
Nun, ganz ehrlich, "best practices" sind nicht universell, daher kann jede Antwort nur auf das jeweilige Problem angewendet werden, das gelöst wird.
Nach meiner Erfahrung gibt es hier jedoch eine Liste allgemeiner XML- und Protokollentwurfselemente.
Tags und Links language-agnostic xml