Wikipedia:Defekte Weblinks/Zukunftsmusik

Das Konzept, die in einem Artikel nicht funktionstüchtigen URL auf einen Abschnitt der Diskussionsseite zu schreiben, ist nicht auf der Höhe der Zeit.

• Bereits während des Botlaufs 2012 war dies kritisiert worden.
• Es verursacht vermeidbare Unruhe auf der Diskussionsseite.
• Problembeseitigungen, egal auf welche Weise, sollen manuell auf der Diskussionsseite in die Liste der Vorlagenparameter eingearbeitet werden – vermeidbarer Zusatzaufwand.
• Insbesondere die Massenverteilung in kurzer Zeit, später auch das Entfernen nicht mehr benötigter Abschnitte, womöglich die Löschung inzwschen geleerter Diskussionsseiten zur Wiederherstellung der redlink-Eigenschaft verursachen hohen Folgeaufwand und belästigen auf den Beobachtungslisten.
• Die einmal geschriebenen Angaben veralten nach einer gewissen Zeit; der Schreibvorgang auf die Diskussionsseiten einschließlich Löschung veralteter Abschnitte dauert vier Monate.

In den Jahren 2013/14 war das Labs/Tools-System noch nicht stabil gewesen; inzwischen ist es zumindest deutlich robuster geworden. Das Vorgängersystem Toolserver war für kleine Werkzeuge ausgelegt, die von Einzelbenutzern gewartet wurden und nach einem halben Jahr Untätigkeit gesperrt wurden.

Ein neues System soll:

• Für alle Wikis der WMF die Verfügbarkeit von URL, die in deren inhaltlichen Seiten vorkommen, in regelmäßigen Abständen vorsorglich prüfen und auf Nachfrage die momentane Verfügbarkeit für eine Seite auflisten; nebst zusätzlicher Hinweise.
• Ein interaktives Formular für menschliche Benutzer anbieten, eine Internet-Schnittstelle (API) für beliebige Werkzeuge und eine Labs-interne Abfrage für befreundete Labs-Tools (Bots) bereitstellen.

Anfrage-Möglichkeiten

Interaktiv

Ein Formular wird jedem Internet-Benutzer angeboten. Eingegeben werden kann alternativ:

1. Eine URL (zu einem Weblink)
   • ein URL-Muster; Host-Komponenten, Beginn des Pfades; Platzhalter
     • Ein Namensraum (alle Inhaltsnamensräume) in einem Wiki zur Filterung
2. Die Bezeichnung einer Seite der WMF (Wiki, dazu entweder Seitenname oder Seitenkennummer) bzw. befreundeter Farm.

Außerdem eine Filterung nach Status (nur funktionierend, nur unerreichbar, zweifelhafte Funktion).

Schließlich ist neben der Analyse einer einzelnen URL/Seite auch die Ausgabe einiger projektweiter (per Wiki) Listen von URL gleicher Eigenschaften vorzusehen:

• Alle Seiten mit einer Spam-URL
• Alle Seiten mit unerreichbar/zweifelhaften URL oder URL-Muster einer bestimmten Domain und ggf. Pfad-Beginn, die zurzeit analysiert werden.

Die Antwort ist

• eine Liste aller URL der Seite mit problematischem Status, optional ergänzbar durch Hinweise zu Webarchiven und typischen Fehlerquellen sowie Spam-Blockade,
  • auf Wunsch auch die vollständige Liste aller URL in dieser Seite mitsamt momentan bekanntem Status.
  • Angezeigt werden die in dieser Sekunde vorhandenen URL; bei kürzlich erst eingefügten URL ist aber möglicherweise noch keine Vorgeschichte und keine Momentanverfügbarkeit bekannt. Aus anderen Seiten kann es aber bereits eine jahrelange Erfahrung geben.
• Weiterhin eine Liste anderer Seiten im selben Wiki, auf denen die URL oder das URL-Muster ebenfalls benutzt wurde; zumindest deren erste 50–100.
  • Durch Vorlageneinbindungen kann diese Liste in die Tausende gehen.
  • Da die Seiten erst mit einem gewissen Nachlauf analysiert werden, sind in der Liste anderer Seiten noch für einige Tage oder Wochen bereits reparierte Einträge vorhanden, was durchaus von Vorteil sein kann.
  • Ggf. wäre eine Ausdehnung auf alle Wikis derselben Farm denkbar.

Die Anfrage nach URL-Analyse einer Wiki-Seite wird immer beantwortet; unabhängig davon, in welchem Namensraum oder welcher Kategorie sie stünde. Sofern sie URL enthält, über die zufällig Erkenntnisse vorliegen, werden diese Informationen auch mitgeteilt. Die interaktive/API-Anfrage zu einer Wiki-Seite löst aber keine Beobachtung der Seite und der darin enthaltenen URL aus; allerdings kann sie dem Seitencrawler übermittelt werden, der überprüfen mag, ob sie die Kriterien hinsichtlich Namensraum oder Kategorie erfüllt und künftig neu zu beobachten wäre.

Ein zusätzliches Formular ermöglicht nur interaktiv die Meldung von URL (und Domains mit kompletten Pfaden), die manuell erreichbar sind, aber fälschlich durch den Automatismus als defekt gezeigt werden.

• Die URL, auf die das zutrifft, werden behandelt wie jede andere auch, aber bei Anzeige der Nichterreichbarkeit wird ein zusätzlicher Hinweis gegeben.
• Sollte eine auf diese Weise gekennzeichnete URL eine reguläre Antwort auf die automatische Abfrage erhalten, wird der Eintrag sofort gelöscht.
• Sechs Monate nach dem interaktiven Hinweis wird dieser immer entfernt.
  • Damit wird vermieden, dass ein falscher Status über die Jahre eingefroren wird. Benutzer müssen die Eigenschaft regelmäßig erneuern.
• Für eine interaktiv als trotzdem erreichbar gemeldete URL kann diese Eigenschaft auch jederzeit interaktiv wieder entfernt werden.
• Es muss vermieden werden, dass über die Meldungsfunktion Vandalismus betrieben wird, womöglich automatisch organisiert.
  • Die Zahl der Meldungen pro interaktives Benutzerprofil ist auf eine pro Minute zu begrenzen.
  • Die Zahl der Meldungen pro Tag über alle Benutzer ist auf einen realistischen Erfahrungswert von einigen Tausend zu begrenzen.
• Wenn für etwa die Hälfte aller URL einer Domain Meldungen vorliegen, sie seien manuell erreichbar, dann wird für die gesamte Domain für sechs Monate unterstellt, alle URL darin wären vermutlich erreichbar.

Ein weiteres Feld lässt die Hinterlegung von genau einer Ersatz-URL für eine nicht erreichbare URL zu.

• Diese Behauptungen aus der Community werden nur unter ausdrücklichem Vorbehalt in den Antworten angezeigt.
• Die Ersatz-URL wird erst dauerhaft gespeichert und angezeigt, nachdem sie auf Funktionalität geprüft wurde und problemlos arbeitet.
• Ob sie tatsächlich den gleichen Inhalt hat wie die ursprüngliche URL, liegt in der Verantwortung des Anwenders.
• Die Angabe kann auch von jedem Internetbenutzer wieder eliminiert werden.
• Falls es sich um eine Seite in einem bekannten Archiv handelt, erfolgt eine Eintragung in der separaten Liste, und nicht als auf eine URL begrenztem Alternativvorschlag.

Meldungen über einzelne URL oder URL-Muster werden nur entgegengenommen, wenn bereits ein Treffer in der Liste der bereits beobachteten URL vorhanden ist.

Die Benutzeroberfläche ist translatewiki-allsprachlich.

Es ist bewusst keine Möglichkeit vorgesehen, eine neue URL in das System einzubringen, ohne dass diese in einer ausgewerteten Seite eines Wiki der WMF (oder befreundeter Farmen) vorkommen würde.

• Andernfalls würde vielfältigen Missbrauchsmöglichkeiten für fremde Zwecke Vorschub geleistet.

Zusätzlich zum Datenbanknamen soll auch die Farm angehängt werden, wobei @WMF die Vorgabe ist.

• Damit soll anderen Wiki-Farmen mit MediaWiki ermöglicht werden, ebenfalls von den Erkenntnissen zu profitieren.
• In Frage kommt @wmflabs zu Erprobungszwecken, Kooperationspartner wie OSM oder vielleicht auch Wikia.
• Auskünfte zu weiteren Seiten mit gleicher URL sind grundsätzlich immer auf die eigene Farm beschränkt.

API

Statt mittels interaktivem Formular kann die Kennung einer Seite im Wiki über eine entsprechend codierte URL abgefragt werden. Anzugeben ist eine oder eine gewisse Anzahl von Seitenkennummern wie etwa

dbname=dewiki@WMF&curid=9301140 und ggf. auch Seitennamen.

Es muss mit unbefugter Nutzung durch Außenstehende gerechnet werden. Automatisierte Anfragen nach einzelnen URL werden deshalb nicht beantwortet.

Die Antwort erfolgt in den API-typischen Formaten JSON oder XML oder aber HTML wie bei einer interaktiven Anfrage.

Die Abfrage kann auch auf ein reines ping für die fraglichen Seiten reduziert werden, ohne eine detaillierte Antwort zu erwarten, so dass die internen Aktualisierungen angestoßen werden.

Skripte können die maschinenlesbaren Formate auslesen und in einer Wiki-Seite verwerten.

Die zulässige Häufigkeit der Abfrage pro IP(-Range) sollte gedrosselt werden, so dass alle sinnvollen Frequenzen unterstützt werden, aber Angriffe nicht zur Überlastung der Server führen.

Intern

Für Werkzeuge innerhalb der Labs besteht (hoffentlich) kein Problem der missbräuchlichen Fremdnutzung, sodass keine Drosselung der Abfragehäufigkeit erforderlich ist.

Die gleiche Abfrage wie als API kann Bot-artig für Namensräume von Wikis oder Kategoriebäume ausgelöst werden; insbesondere der Ping-Modus.

Ein separater Mechanismus (der als eigener Prozess laufen sollte und unabhängig programmiert werden kann) nimmt die regelmäßige Einspeisung neuer Kombinationen dbname@farm:pageid in das System zu überwachender Seiten der WMF vor.

• Nur der interne Mechanismus hat das Recht und die Möglichkeit, eine dbname@farm:pageid in das eigentliche System einzubringen oder zu entfernen.
• Gelöschte Seiten könnten mitgeteilt werden; trifft das Hauptsystem bei einem Überwachungslauf allerdings auf eine gelöschte Seite, dann entfernt es diese selbsttätig aus der Datenbank.
• Nur Seiten mit Inhaltsmodell wikitext werden in die Datenbank aufgenommen.
• Die Kommunikation mit interessierten Menschen, in welchen Wikis welche Namensräume oder Kategoriebäume oder auch einzelne Seiten hinsichtlich URL analysiert werden sollen, ist vollständig vom Analysesystem zu trennen.
• In geeigneten zeitlichen Perioden können für jedes Wiki alle neu angelegten oder wiederhergestellten Seiten ab dem letzten relevanten Zeitpunkt aufgelistet, gefiltert und dem Analysesystem gemeldet werden; gleichfalls neu in Kategoriebäumen erscheinende Seiten.
• Im Prinzip ist auch zu ermöglichen, Bezeichner existierender Seiten ebenfalls wieder aus dem Analysesystem zu entlassen.
  • Für eine Seite, die einmal in einem Kategoriebaum vorkam, ist primär keine Möglichkeit zur Entfernung beabsichtigt.
  • Um eine Seite aus der Analyse zu entfernen, müssen alle zu diesem Wiki definierten Einschlusskriterien abgeprüft werden.
• Der zeitliche Ablauf ist untergeordnet. Bis zu einer URL die allererste Abfrage erfolgt, können Wochen vergehen; bis über eine Nichterreichbarkeit eine gesicherte Grundlage vorliegt, dauert es Monate. Bis über eine neu angelegte Seite und deren zuvor nie gesehene URL Erkenntnisse angezeigt werden können, mag es also immer eine Weile dauern.

Problem: Zeitlicher Vorlauf

Würde erst im Moment der Anfrage zu einer Seite damit begonnen, womöglich über hundert URL in der Seite abzufragen, und dann gar eine Antwort in der nächsten Sekunde erwartet werden, so muss das versagen:

• Es dauert Zeit, bis jeder angefragte fremde Server geruht, eine Antwort zu senden.
• Ein fremder Server kann für einige Minuten überlastet oder abgeschaltet sein; Dokumente können wegen einer vorübergehend kaputten Festplatte für einige Tage nicht erreichbar sein.

Das würde zur falschen Einschätzung führen, dass eine URL defekt sei, im Sinne einer dauerhaften Nichterreichbarkeit. Nun würde völlig sinnlos begonnen, dass Autoren Ersatz dafür suchen, und womöglich eine anscheinend nicht belegte enzyklopädische Aussage aus einem Artikel entfernt wird.

Tatsächlich bedarf eine gesicherte Anzeige nicht mehr verfügbarer URL mehrerer Wochen Vorlauf, um später Anfragen qualifiziert beantworten zu können.

Problem: Inhaltliche Eignung

Automatische Prozesse können die mutmaßliche Erreichbarkeit einer URL oder die Nichterreichbarkeit registrieren.

Im Fall der Erreichbarkeit ist aber nicht gesagt, dass der Inhalt noch der gleiche oder ähnlich dem ist, der gesehen wurde, als der Weblink eingefügt wurde.

Es könnte auch schlicht auf der Seite stehen:

     Diese Domain steht zum Verkauf. Überweisen Sie 1000 Dollar an   ...

Archive

Bekannte Hinterlegungen in Archiven sind ebenfalls mit der jeweiligen URL zu verknüpfen.

Dabei wird pro Archivtyp jeweils genau eine bestimmte Versionsbezeichnung hinterlegt, von der anzunehmen ist, dass sie das Ergebnis eines Aufrufs der URL zu allen Zeiten gut wiedergibt; ist zwar eine Archivierung erfolgt, jedoch noch keine bestimmte Version ausgewählt worden, wäre eine leere Zeichenkette etc. zu speichern.

Webseiten, die permanent ihren Inhalt ändern, eignen sich nicht für einen statischen Zugriff mittels URL; mindestens nicht für eine Empfehlung bestimmter Archivseiten durch das Werkzeug. Hier ist die Auswahl bestimmter Versionen manuell zu blockieren, was nur administrativ aufgehoben werden könnte.

Bereits einmal archivierte Webseiten können auch nachträglich wieder depubliziert werden; müssen sich also auch nachträglich aus den Vorschlägen des Werkzeugs entfernen lassen. Das soll automatisch durch vierteljährliche Routinebesuche gesichert werden.

Innere Abläufe

Vorgesehen ist im Groben folgender Prozess:

• Sobald ein Name einer Wiki-Seite abgefordert wird, wird er in die verschiebungsresistente pageid gewandelt; für die interaktive Anzeige zur pageid der momentane Seitenname dargestellt.
• Sobald eine Wiki-Seite aktiv abgefordert wird, wird geprüft, ob sie die Bedingungen für Namensräume und Kategorien im Wiki erfüllt; falls ja, ob bereits eine Kombination Wiki-Name+pageid in der weltweiten Liste aller beobachteten Seiten eingetragen ist.
  • Falls kein Eintrag vorhanden war, wird er neu angelegt.
  • Im Vollausbau muss mit bis zu 100 Millionen interessanter Seiten gerechnet werden; zumindest 10 Millionen betreuter Seiten sind schnell erreicht.
  • Falls am heutigen Kalendertag noch kein Datumsstempel für aktive Anfragen registriert worden war, wird er aktualisiert.
• Turnusmäßig geschieht im Rahmen der Kapazitäten Folgendes mit den von außerhalb vorgegebenen Konfigurationen für Namensräume und Kategorien zu jedem Wiki (Standard: Hauptnamensraum jeder Wiki-DB, die in die Konfiguration eingetragen ist); weitere Einschluss- und anschließende Ausschlusskriterien sind vorstellbar (Vorlagen, Wikidata-Eigenschaften):
  • Alle ein oder zwei Wochen wird der Status aller beobachteten Namensräume und Kategorien im Wiki abgefragt, und jede davon erfasste pageid wird besucht:
    • Der page record zu dieser Wiki-Seite erhält ein “touch” mit der passiven Tagesnummer.
    • Ein Flag für erforderliche URL-Analysen wird gesetzt.
  • Nachdem für alle Wikis die aktuellen Konfigurationen für Namensräume und Kategorien abgerbeitet wurden, werden nun alle page records besucht:
    • Falls die Seite im Wiki in diesem Moment gelöscht gewesen ist, wird der Eintrag zur Wiki-Seite gelöscht.
    • Falls der letzte “touch” älter als einige Monate ist, hat das Wiki das Interesse an dieser Seite verloren, sie wurde vielleicht in einen anderen Namensraum verschoben oder entkategorisiert, und der Eintrag wird jetzt gelöscht.
      • Kurzzeitige Umkategorisierungen und vorübergehende Verschiebungen in andere Namensräume werden von diesem System ignoriert.
    • Falls der Flag für erforderliche URL-Analysen gesetzt worden war, wird er zurückgesetzt und die aktuelle Menge der URL wird abgefragt, und diese werden wie auch bei einer interaktiven Anfrage ggf. der Menge der beobachteten URL hinzugefügt.
      • Die URL werden normalisiert.
      • Beispieldomains wie example.org sind gesondert einzustufen und brauchen nicht angefragt werden.
      • Syntaktisch falsche URL sind gesondert einzustufen und brauchen nicht angefragt werden.
    • Die Rückverweise, welche URL von diesem page record benutzt werden, sind zu aktualisieren (zunächst zu löschen). Damit entsteht bewusst ein lag von einigen Tagen oder Wochen, die noch Hinweise liefert, wo kürzlich eine URL verwendet worden war, selbst wenn sie in der momentanen Seitenversion nicht mehr auftritt. Dies kann genutzt werden, um in der Versionsgeschichte kürzliche Fixe nachzuvollziehen.
    • Für jede der aktuell vorhandenen URL wird der Datumsstempel der URL für Aktualisierungsbedarf auf den heutigen Tag gesetzt, und es wird wieder ein aktueller Rückverweis von der URL auf den page record eingetragen.
  • Der Datumsstempel für passive Updates der Wiki-Seite wird aktualisiert; das heißt um die vorgesehene Periode ab dem heutigen Tag vergrößert.
    • Bei entsprechend großer Anzahl von Wiki-Seiten könnte theoretisch der Fall eintreten, dass der Zeitbedarf für das Abfragen aller Wiki-Projekte größer wird als die vorgesehene Periode; dann kommt es schlicht zu einer Dauerschleife, bei der die am längsten zurückliegenden passiven Abfragen aktualisiert werden.
  • Zusammengefasst könnte man die Aufnahme einer Wiki-Seite als eine Art Beobachtung dieser Seite auffassen.
• Wenn der Zeitraum für einen Durchgang vier Wochen übersteigt, ist Neuaufbau des Systems mit zusätzlichen Ressourcen (Hardware, Netzwerk) erforderlich.
• Für die Liste aller bekannten URL gilt folgende Prozedur:
  • Sie wird nach Datumsstempel für Aktualisierungsbedarf sortiert.
  • Diejenigen Einträge, die deutlich älter sind als die Umlaufzeit für Wiki-Seiten zuzüglich Ausfallzeiten, also vor zwei oder drei Monaten zuletzt abgefordert wurden, werden gelöscht.
    • Sie kommen auf keiner aktiven Seite mehr vor.
    • Sie waren vielleicht kaputt gewesen oder wertloser Spam und wurden überall ersetzt, oder enthalten jetzt etwas wie domain for sale.
    • Sie belasten das Crawler-System nutzlos.
  • Diejenigen URL, die noch nie kontaktiert wurden, werden initial belegt.
  • Danach wird, beginnend mit dem ältesten Abruftag, jede URL angefragt, bis zu eine Minute gewartet und das Ergebnis verbucht. Letzter Abruftag ist der heutige Tag.
  • Die Reihenfolge soll sich zufällig über den gesamten Durchlauf verteilen und nicht nach Domains sortiert werden. Oft blockieren Domains, wenn sie schnell hintereinander von der gleichen IP und UA-Kennung kontaktiert werden.

Auch hier gilt: Wenn die Umlaufzeit für einen Durchgang über vier Wochen steigt, ist eine physische Systemerweiterung erforderlich.

Größenbetrachtung

• Für eine Handvoll der größten Wikipedien kommen zehn Millionen Artikel zusammen.
• Die Systemkapazität ist auf hundert Millionen Seiten auszulegen.
• Die Rate von unterschiedlichen aktiven URL pro Artikel liegt in der deutschsprachigen Wikipedia bei etwa drei (Schnappschuss: 5.584.413 aktive URL in 1.879.178 Artikeln).
  • Somit wird mit vielleicht fünfzig Millionen URL für die größten Wikipedien begonnen; einmal aufgenommene URL verweilen sicher ein halbes Jahr im System, selbst wenn sie nur kurzlebig in einem Artikel erschienen waren.
  • Netzwerkverkehr muss mit einer halben Milliarde URL rechnen, selbst wenn das erst im Vollausbau über alle Wikis erreicht wird.
• Ein Monat hat zweieinhalb Millionen Sekunden, gelegentliche Ausfallzeiten des Systems einmal abgezogen.
• Um jede von fünfzig Millionen URL einmal im Monat zu kontaktieren, sind 20 Abfragen pro Sekunde auszuführen.
  • Wenn jede Abfrage bis zu einer Minute Antwortzeit erlaubt (die meisten antworten sehr viel schneller), wären über 1000 Connections offen zu halten und simultan zu bedienen.
  • Das System muss aber 20 Statusmeldungen pro Sekunde verdauen und einarbeiten können; bei maximaler Auslegungslast 200.
• Parallel zur Last von URL-Kontakten müssen die Abspeicherung in die Datenbank und die Beantwortung von Abfragen aus der Wiki-Welt zum Status bestimmter Wiki-Seiten oder einzelner URL beantwortet werden und ggf. neu in die Datenbank eingetragen werden; außerdem turnusmäßig die EL beobachteter Wiki-Seiten abgefragt werden.
• Die Größenbetrachtungen gehen vorrangig von Wikipedien aus, und den kleinen Schwesterprojekten. Hinzu kommt dann noch Wikidata, wo irgendwann mal URL als Belege für jede Einzelinformation gesammelt werden müssten, was in den zweistelligen Millionenbereich ginge, wobei auch diese URL mit einer Rate von vielleicht 10 % alle zwei Jahre unerreichbar würden.

Technische Details

HTTP

• Die Anfragen sind zunächst als HTTP HEAD zu stellen.
• Die meisten Server werden das auch sinnvoll beantworten.
  • Sinnvoll ist die Antwort dann, wenn sie MIME und Content-Length sowie einen Statuscode enthält.
• Einige wenige Server geben nur auf HTTP GET verwertbare Antworten.
  • Hier ist die Anfrage mittels HTTP GET zu wiederholen.
  • Die entsprechenden Domains sollten in einer Tabelle registriert und für 200 Tage nur noch per GET abgefragt werden; anschließend wird dieser Sonderstatus gelöscht und müsste ggf. erneut erworben werden.
• Die Anfrage muss Accept-Felder enthalten; namentlich
  • HTTP/1.0
  • Accept: */*
  • Accept-Language: *
  • Accept-Encoding: gzip, deflate
  • Connection: keep-alive
  • Cache-Control: max-age=0
• Es sollte ein expliziter User-Agent mit Kontaktadresse geschaffen werden und zur Eintragung in useragentstring.com gemeldet werden.

Es könnte Probleme mit https/http und Gültigkeit von Zertfikaten geben.

Protokoll und Domain

Ressourcen-URL

Es werden nur URL der Protokolle http oder https, ftp, ftps usw. aufgenommen, bei denen im WWW eine Antwort möglich ist. URL wie etwa mailto: haben keine Server-Verfügbarkeit und liefern keinen HTTP-Status.

Beispiel-Domains

Die in RFC 2606 aufgelisteten Domains wie example.org werden nicht in die Liste der zu einer Seite gehörenden Domains aufgenommen.

Domain unerreichbar

Wenn eine Anfrage einen plausiblen 502 etc. Code bzw. Netzwerkfehler liefert, ist davon auszugehen, dass alle offenen Anfragen dieses URL-Zyklus ebenfalls 502 etc. ergeben und unerreichbar sind; sie können sofort mit dem Tagesdatum und diesem Statuscode versehen werden und belasten den Netzwerktraffic nicht unnötig. Falls sich erweisen sollte, dass der Code 502 unzuverlässig vergeben wird, können auch mehrere dieser Antworten im Zyklus abgewartet werden.

Mit dem nächsten URL-Durchlauf wird wieder unvoreingenommen mit dieser Domain umgegangen. Vielleicht wurde die Stromrechnung inzwischen bezahlt.

Bei schweren Netzwerkfehlern auf DNS-Ebene (Domain nicht auflösbar) können für diesen Durchgang sofort alle URL der gleichen Domain als unerreichbar markiert werden. Beim nächsten Durchgang mag die Domain (wieder) registriert sein, oder ein Serverproblem der DNS wurde behoben.

Domain-Besonderheiten

Für auffällig werdende Domains und Subdomains ist eine Tabelle zu führen:

Art	Tagesnummer
	Erstbeobachtung	Zuletzt
Umschaltung von http nach https erforderlich (secure site)
Umschaltung von https nach http erforderlich (kein gültiges Zertifikat)
Anfrage mit HTTP GET statt HTTP HEAD erforderlich (nur intern)
DNS-Fehler (Domain nicht registriert)
Schwerer Server-Fehler (Server down, keine Antwort)

Wenn der Tag der letzten Beobachtung 10–30 Tage zurück liegt, ist ein neuer Versuch zu unternehmen und die Tagesnummer zu aktualisieren.

• Ist die Eigenschaft nicht mehr gegeben, ist der Eintrag vollständig zu löschen.
• Wenn der Tag der letzten Beobachtung 100 Tage zurück liegt, werden entsprechende URL nicht mehr beobachtet, die Gültigkeit ist ungewiss und der Eintrag ist durch einen turnusmäßigen Wartungsprozess zu löschen.

Auf eine Domain bezogenene Eigenschaften gelten auch für alle Subdomains, aber Subdomains können individuelle Eigenschaften haben, die nicht auf andere Subdomains zutreffen.

Auch wenn über eine angefragte individuelle URL noch keine Erkenntnisse herangereift sind, können über mehr als 100 Tage seit Erstbeobachtung konsolidierte Informationen nach außen gegeben werden.

• Primär ist die Tabelle für den internen Gebrauch gedacht.

Domain-Syntax

Die Domain zu einer Ressource im www muss einige Bedingungen erfüllen. Die MediaWiki-Software markiert sie als Verlinkung und setzt sie auf die Liste der externen Links, auch wenn sie im www nicht erfolgreich sein kann.

Kriterien für ungültige authority parts (RFC 3986 etc.):

• unsichtbarer Unicode enthalten
• IPv4 mit ungültigen Zahlenwerten
• Wenn keine IP, dann Domain:
  • Keine Trennung von TLD und 2nd level domain
  • Domain-Komponente beginnt nicht mit Buchstabe oder aber endet nicht auf Buchstabe oder Ziffer
• port ungültig (keine ganze Zahl)

Beispiele für ungültige Domains:

• http:///example.org
• http://http://example.org/
• http://docs/about.htm
• [http://a document title http://example.org/and/this/is/the/URL]
• http://example.com:8o8o/foo/bar
• http://example.c/forget/it

Externe Links in einer Seite

Die externen Links in einer Seite sind aus zwei Datenbanktabellen zusammenzustellen:

1. Direkt: externallinks als URL.
2. Indirekt: iwlinks

Im zweiten Fall können nicht nur andere Wikis derselben Farm enthalten sein, sondern auch „Pseudo-Interwikis“

• Diese API-Abfrage enthält auch verborgen: https://dx.doi.org/10.1000/182

Die Special:Interwiki ist anscheinend für die geamte Farm identisch; wird zumindest für WMF zentral auf meta: gepflegt. Die zugehörige Tabelle interwiki ist aber auch lokal in jedem Wiki vorhanden, aus dem verlinkt wird (API: interwikimap).

• Über Ersetzung von $1 in iw_url durch iwl_title kann sofort die URL gebildet werden. Es ist https anzunehmen.
• Das Flag local ist dabei wichtig:
  1. Bei der Aufnahme von URL in die Tabelle der zu besuchenden URL sind die local zu ignorieren.
  2. Bei der Auskunft über den Momentanstatus einer Seite (interaktiv/API) können diese URL spontan ausgewertet werden und dadurch ggf. Hinweise auf fehlende Zielseiten in anderen Wikis gegeben werden.
     • iw_wikiid ermöglicht ggf. einen Direktzugriff.

Analyse der URL einer Seite

Wenn eine Seite im Wiki angesprochen wird, dann ist für sie die Liste der externen Links verfügbar, die die MediaWiki-Software erkannt hat.

Diese Liste ist sofort zu filtern, die URL zu klassifizieren:

• Ressourcen-URL – sonst ignorieren
• Domain syntaktisch gültig – sonst sofort als ungültig einstufen, keine Kontaktaufnahme mehr
• Die URL ist dann zu normalisieren.
  • Dieser Schritt kann integriert mit der Gültigkeitsprüfung erfolgen.
• Beispiel-Domain – diese ignorieren
• Domain gehört zur eigenen Farm – diese im Prinzip ignorieren
  • In den interaktiven und API-Antworten zu dieser Seite jedoch Erreichbarkeit prüfen, sofern ohnehin in den EL aufgelistet.
  • Falls 404, dann Hinweis; jedoch keine Aufnahme in die URL-Tabelle.
• Globaler oder lokaler Spam in Farm und Wiki – sofort entsprechend einstufen, keine Kontaktaufnahme mehr von dieser Seite aus auslösen

Anmerkungen zu verdächtiger Syntax in path/query wie ein kodiertes bidirektionales Steuerzeichen können der URL sofort attribuiert werden.

URL-Normalisierung

Auf der EL sind die URL von MediaWiki bereits auf bestimmte Art und Weise einem Encoding und Escaping unterzogen worden. Um gleich wirksame URL nur genau einmal zu handhaben, ist eine zusätzliche Normalisierung vorzunehmen:

• Der Host-Anteil (insbesondere die Domain) sind in Kleinschreibung umzuwandeln.
• IDN sind als Punycode zu speichern; desgleichen ggf. im Pfad.
• Der Pfad besteht aus mindestens einem /.

Alle Normalisierungen durch Escaping sind präzise zu dokumentieren.

• Ein API-Zugang sollte zu einer beliebigen URL die normalisierte Form liefern.
• Wenn interaktiv Informationen zu einer URL angefragt werden, ist die Antwort unter Darstellung der normalisierten Form zu geben.

Syntaktisch falsche URL sind gesondert einzustufen und werden nicht standardisiert; sie erhalten auch keine Attribuierung und werden deshalb auch nicht in die Watchlist beobachteter URL aufgenommen.

Spam

Die URL werden mit der globalen Spam-Liste und der Spam-Liste des Wiki abgeglichen. Für Spam-URL werden keine Verfügbarkeitsabfragen ausgeführt.

• Eine URL, die lokal oder global geblockt ist, trägt zur Liste der URL nicht mit einer Aufforderung zur Verfügbarkeitsprüfung bei.
• Andere Verwendungen der geblockten Domain können im lokalen Wiki mit gewöhnlicher Weblinksuche gefunden werden.

Über lokale Blockierung auf anderen Wikis wird nicht informiert. Wenn die Admins auf einem der 1000 WMF-Wikis beschließen, die New York Times auf die Liste der verbotenen Hetzschriften zu setzen, würde sonst bei jeder Seite jedes Wiki jede Verlinkung als unerwünscht angezeigt werden.

Globale Blockierungen betreffen immer nur die Farm und sind keine Eigenschaft der URL als solcher.

Fehlerhafte Statuscodes

Es gibt Server, die falsche Fehlernummern (400er und 500er) zurückgeben. Anhand von Plusibilitätsbetrachtungen (500er haben nur geringe Größe) lassen sich einige Fehlermeldungen in der Einstufung korrigieren.

Eine 500er Antwort kann keinen Server und keinen MIME-Typ enthalten, und verschiedene andere Merkmale weisen darauf hin, dass sie vom Zielserver stammen.

Eine 400er Antwort kann eigentlich nur text/plain oder text/html sein; eine application weist auf einen falschen Fehler hin.

Erreichbarkeitsgeschichte

Sie ist das Kernstück des Auskunftsystems.

Zu jeder URL sind etwa drei bis fünf Einträge nach folgendem Muster gespeichert zu halten:

• Ein Byte mit dem Statuscode
• Tagesnummer, an dem dieser Statuscode zuerst beobachtet wurde
• Tagesnummer, an dem dieser Statuscode zuletzt beobachtet wurde

Zwischen beiden Tagesnummern hatten ausnahmslos alle Abfragen den identischen Statuscode geliefert.

• Der vorangehende Datensatz beschreibt einen anderen Statuscode mit der ersten und letzten Tagesnummer dieser Beobachtung.
• Eine Abweichung im jüngsten Statuscode schiebt irgendwann den ältesten Datensatz aus dem Gedächtnis heraus, wenn die Maximalzahl zulässiger Einträge überschritten wird.

Als „Statuscode“ wird nur ein Mapping der wenigen Dutzend standardisierter HTTP-Codes, Netzwerk-Codes und interner Kodierungen gespeichert; für die Kommunikation mit der Außenwelt auf 404, 305, 200, 502 usw. gemappt und für interaktive Abfragen um textliche Erläuterung ergänzt.

URL mit Besonderheiten

Es wird eine Tabelle für URL-Muster und Domains geführt, die allgemeine Auffälligkeiten protokolliert:

• example.org
• HTTP GET erforderlich
• Page moved (new URL) from 301–307
• Begrenzung der Anfragen pro Zeiteinheit
• Spam
• Zertifizierungsprobleme
• Domain ist manuell erreichbar, nicht aber durch Automatismus
• Abhängigkeit vom Referrer.

Die Einträge haben für jeweils ein halbes Jahr Gültigkeit und müssen danach aufgefrischt werden oder werden gelöscht.

URL mit Zusatzinformationen

Bei jeder URL, für die das bekannt ist, wird ein Verweis auf Zusatzinformationen geführt. Dabei geht es um zwei Fälle:

1. Von Standardressourcen abweichender MIME-Typ nebst Zahl der KiB.
2. Archiv-URL bekannt.
   • webcitation
   • archive.org - Zweig
   • …

Statusinfo

Es genügt ein Byte, um die für uns relevanten Statusinformationen zu speichern.

• Der HTTP-Statuscode deckt nicht alle relevanten Fälle ab.
• Er ist auch teilweise irrelevant.
• Der vom Server behauptete Statuscode kann offenkundig falsch oder unplausibel sein und von uns anders eingestuft werden. Die Typen 19, 20 und auch andere sind zu hinterfragen, ob nicht trotzdem eine Ressource abrufbar ist, und dann ggf. durch unseren Typ 7 zu ersetzen.
  • Wenn mehr Content-Length vorhanden ist, als eine Fehlerseite erfordern würde, oder diese ungewöhnlichen MIME enthält, könnte der Statuscode irreführend sein.

Type	HTTP	Issued by	Explanation
0	–	us	No attempt yet.
–	100–	Server	Live; not recorded.
1	200 304		Everything fine.
2	201–299 300		Content should be available on request in wiki page
7	–	us	autocorrected HTTP status code; meaningless warning
8	301	Server	Moved Permanently (different URL recorded)
9	302		Found (different URL recorded)
10	303		See Other (different URL recorded)
11	305		Use Proxy (different URL recorded)
12	306		Temporary Redirect (different URL recorded)
13	307		Permanent Redirect (different URL recorded)
16	400 414 422 431 500		Syntax problem Server overload (thread quota exceeded)
17	401 402 403 407 451		Authentification required, no public access
18	404		Not Found
19	406		Not Acceptable (how comes?)
20	409 411 412 417 418 420 424 425 428 444 449 4** 506 508		Strange answer on such question; probably wrong code
21	410		Gone
22	415		Unsupported Media Type, but requested with */*
23	416		Requested range not satisfiable
24	423		Locked
25	510		Not Extended
26	(*)		Unknown Status Code
32	405		Method Not Allowed
33	408		Request Time-out
34	413		Request Entity Too Large
35	426		Upgrade Required
36	429		Too Many Requests
37	431		Request Header Fields Too Large
38	501		Not Implemented (HTTP-HEAD → HTTP-GET?)
39	502 504		Bad Gateway (other local server down)
40	503		Service Unavailable
41	505		HTTP Version not supported
42	507		Loop Detected
43	509		Bandwidth Limit Exceeded
63	–	us	Change between http and https etc., then fine (other URL record exists with details)
64	–	Network	General network problem.
65			DNS refused.
66			DNS answered: “Unknown domain”.
67			Host is IP and server does not respond
128	Syntax	us	URL accepted by MediaWiki but invalid

Kalender

Es ist nicht erforderlich, jeden Datumsstempel mit einem vollen Datumsformat auszustatten.

• Vielmehr wäre es intern ausreichend, die Tage etwa ab 1. Januar 2017 zu zählen.
• 65535 Tage würden knapp bis an das Jahr 2200 heranreichen.
• Berechnungen von Fristen wären effizienter, Speicherplatz einzusparen.
• Nur für die Darstellung nach außen ist dies umzurechnen, wobei ohnehin oft nur Angaben wie „vor zwei Wochen“ oder „seit sechs Monaten“ oder „bereits vor mehr als zwei Jahren“ anzuzeigen sind; die genauen Kalendertage kommen in der Außendarstellung eigentlich nicht vor.
• Einmal täglich ist die aktuelle Tagesnummer global zu aktualisieren; der Rest sind Differenzen von Tagesnummern.

Über das Julianische Datum, ebenfalls eine Tageszählung, lässt sich die interne Tagesnummer in das Julianische Datum der Außenwelt und dieses dann über Standardfunktionen in eine Kalenderanzeige wandeln.

Farmen

Um die möglichen Farmen abzubilden, genügt eine kleine Ganzzahl.

Code	Meaning
0	wmflabs	Test environment
1	WMF	First productive wikis. Default assignment.
2	…	Good friend, etc.

Es muss sowieso ein Mapping auf korrespondierende Server erfolgen; zu jeder Farm ist also auch eine Netzwerkadresse usw. erforderlich und eine Zeichenkette WMF würde auch noch nicht zur Kontaktaufnahme führen.

Weiterhin muss der Eintrag zu jeder Farm auch ein Domain-Muster enthalten, das die Identifizierung von inneren Verlinkungen zu eigenen Seiten der Farm ermöglicht.

Code	Meaning	Internal Domain pattern
0	wmflabs	\.beta\.wmflabs\.org$
1	WMF	\bmediawiki|wik(?:i(?:books|data|media|news|pedia|quote|source|species|versity|voyage)|tionary)\.org$

Page watchlist

Record format

primary key	farm	dbname	pageid	day of last page touch	URL list needs update
binary, internal	int	string	int	int	boolean

The page feeder bot is crawling about once a week through all wikis.

• For all pages in configured namespaces and categories the page watchlist is checked whether a record exists, otherwise it will be created now.
• For each page record the day of last page touch will be set, and URL list needs update becomes true.
• The result is a unified match of all current namespace and category members, or which inclusion and exclusion criteria and rules anyone invents later. Exclusion will finally clear the URL list needs update flag.

In a second run, all these page records will be inspected.

• Overaged records (not touched for longer period) and records of deleted pages will be deleted; also any other content model than wikitext.
• For each record that needs URL updating all relevant URL on page EL will be inserted into the URL watchlist, if not yet present.
  • They will be created with an empty history.
• In URL watchlist the day of last URL touch will be set on “today”.
• If local or global spam list matched, this will update a spam backtrace table of this URL rather than a request for www accessibility.

On interactive query of a certain page it might be checked whether that one matches namespace or category criteria of that wiki, and could be added right now.

• Otherwise that page might receive touching the same way as performed on regular base.

URL watchlist

Record format

primary key	binary, internal	Unique for scheme host port path+query.
scheme	string	http, https, ftp, ftps, sftp etc. Resources only.
host	string	Normalized downcased punycode. Domain or IP.
port	int	0 – not provided
path+query	string	As delivered by EL; at least /
day of last URL touch	int	Touched by page watchlist loop. An URL not touched for some 100 days by any page loop will be deleted from the list, including all dependencies.
day of last website query	int	May be used for sorting the crawler loop; oldest entries first. Updated on dealing with this URL, successful or not.
History record	binary	Three or five entries. From one entry to next a change in state is required; else the youngest entry tells about continous constant answers until today (day of last website query).
MIME	int/string	Notable MIME type (unified, mapped, perhaps coded); mostly unrecorded.
length	int	Only if MIME field provided. Full KiB.
Archives	set	List of archive entries, if any; also human suggestion for replacement.

URL/page cross reference

Record format

primary key of page entry	binary, internal
primary key of URL entry	binary, internal

Dieser Rückverweis gibt an, welche Seiten in den letzten Tagen oder Wochen ebenfalls eine bestimmte URL verwendet hatten.

Er ist nicht dazu vorgesehen, zu ermitteln, welche URL in einer bestimmten Seite auftreten. Hierzu ist ausschließlich die momentane Wiki-Seite betreffend EL abzufragen.

Bei interaktiven Anfragen können aus demselben Wiki, zumindest aus derselben Farm andere Seiten benannt werden, in denen diese URL ebenfalls vorkommt oder bis vor kurzem noch vorgekommen war.

Bei einer ungefähr wöchentlichen page loop werden alle Einträge zu dieser Seite gelöscht und durch die aktuellen URL ersetzt.

Trennung der Module

Verschiedene Teilaufgaben sollen durch unterschiedliche voneinander unabhängige Softwarekomponenten realisiert und nur durch API verbunden werden, so dass sie ggf. auf unterschiedlichen Hardwarekomponenten betrieben werden können:

• Datenbank und Selbstverwaltung (Kernfunktion)
• Krabbeln im www: Übermittlung von Statusinformationen an die Datenbank
• Einzelauskünfte zu einer Wiki-Seite:
  • Interaktives Formular
  • API-Zugang: Abfrage des Status aller URL der Seite.
  • Dadurch implizite zufällige Aufnahme einer Wiki-Seite in das System, sofern keine Policy dem entgegenstünde.
• Massenhafte Einspeisung der pageid von Kategoriebäumen und Namensräumen einzelner Wiki-Projekte in die Datenbank; Einpflegen von Seitenlöschungen, Spam-Blacklists abbilden.
• Kommunikation mit Web-Archiven und dem dortigen Bestand an Seiten; mögliche Depublikation.

MIME

Wenn ein Server mit einem ungewöhnlichen MIME-Typ antwortet, der zunächst nicht von einem klassischen Browser unterstützt wird, sondern die Erfordernis von Zusatzsoftware nahelegt, dann soll dies gesondert zu den Eigenschaften der URL vermerkt werden, damit in der Wiki-Seite den Lesern entsprechende Hinweise gegeben werden können. Nicht weiter vermerkt werden HTML, PNG, SVG, GIF usw. Da für unbekannte Typen auch keine spezifische Software empfohlen werden kann, werden alle nicht identifizierbaren Ressourcen als binary vermerkt; bevor diese Einstufung erfolgt, sollte aber das erste Dutzend Bytes auf wohlbekannte magic inspiziert und der Inhaltstyp ggf. angepasst werden.

Gleichzeitig mit einem speziellen MIME-Typ soll auch die Content-Length in ganzen KiB registriert werden.

Server verwenden oft nicht den standardisierten MIME-Typ; die Antwort wird interpretiert und auf ein intern vereinheitlichtes Schlüsselwort abgebildet.

Observed MIME	Mapping
audio/mpeg	mpeg
audio/ogg	ogg
application/ogg
audio/mpeg4-generic	mpeg4
application/mp4
application/mpg4
application/rtf	rtf
text/rtf
image/tiff	tiff
image/vnd-djvu	djvu
text/css	css
text/csv	csv
application/zip	zip
application/x-zip
application/x-zip-compressed
application/gzip	gzip
application/x-gzip
application/vnd.adobe.flash-movie	flash
application/flash
application/x-flash
application/x-shockwave-flash
video/flash
video/x-flash
application/pdf	pdf
application/x-pdf
application/xpdf
application/PDF
application/acrobat
application/vnd.adobe.pdf
application/postscript	postscript
application/vnd.microsoft.excel	msexcel
application/vnd.msexcel
application/vnd.ms-excel
application/x-msexcel
application/msexcel
application/ms-excel
application/vnd.microsoft.mspowerpoint	mspowerpoint
application/vnd.microsoft.powerpoint
application/vnd.ms-powerpoint
application/mspowerpoint
application/ms-powerpoint
application/vnd.microsoft.msword	msword
application/vnd.microsoft.word
application/vnd.msword
application/vnd.ms-word
application/msword
application/ms-word
text/msword
text/ms-word
(various)	binary

Wer kann das, wer macht das

• Mitarbeit von Freiwilligen
  • Gifti
  • Dispenser hatte einmal ein ähnliches System auf dem Toolserver betrieben; scheint privat noch auszuwerten.
  • Bot-Betreiber mit einschlägigen Erfahrungen, auch der enWP.
  • User:Frog23/Dead Link Finder
• WMF
  • WMDE – ggf. Mitwirkung

Die produktive Vollversion, die über Jahre zuverlässig rund um die Uhr arbeiten soll, wird unter dem Dach der WMF angesiedelt werden müssen.

• Die physische Kapazität eines normalen Labs-Projekt wird im Vollausbau überfordert sein.
• Es werden mehrere unabhängige Server nur für diese Aufgabe benötigt, die auch mit hinreichender Ausfallsicherheit permanent Anfragen beantworten sollen.
• Allein für den Crawler würde es sich vermutlich lohnen, ein eigenes Glasfaserkabel zu verbuddeln.

In Analogie zu Citoid, Graphoid oder schließlich Parsoid könnte das neue System „Weboid“ heißen.

Mock-Up

Basierend auf den 2015/2016 gesammelten Erkenntnissen über URL-Verfügbarkeit könnte ein experimentelles Werkzeug auch bereits produktiv eingesetzt werden.

Es soll noch nicht den vollen Umfang und die Architektur des geplanten Systems enthalten, kann aber bereits die wesentlichen Funktionen für Standardaufgaben anbieten.

Gemeinsam ist allen Anfragen, dass die Identifikation einer Wiki-Seite vorgegeben wird; das Ergebnis ist eine der Anforderung entsprechend formatierte Auflistung aller in der Wiki-Seite enthaltenen URL, ggf. reduziert auf diejenigen, über die Erkenntnisse vorliegen, und die jeweiligen Erkenntnisse zur URL.

1. Gadget-Abfrage
   • Über etwas wie
     https://iw.toolforge.org/giftbot/externalLinkProblem?dbname=dewiki@WMF&pageid=9301140
     kann mit einem Funktionsaufruf in aktivem JavaScript bedient werden, wobei diese Ergebnisse dann innerhalb der HTML-Ansicht der zugehörigen Wiki-Seite präsentiert werden.
   • Enthalten sind nur URL, die mutmaßlich nicht erreichbar sind.
   • Format siehe: en:User:PerfektesChaos/js/externalLinkProblem/query
   • Weil das Ergebnis als aktives JavaScript innerhalb der Zielseite ausgeführt werden soll, muss der gesamte auf den Labs ausgeführte Quellcode auch in genau dieser Version auf den Labs offengelegt werden, und es muss deutlich gemacht werden, wie diese Labs-Antwort daraus entsteht.
2. URL-Parameter: Seiteninformationen
   • Über etwas wie
     https://iw.toolforge.org/giftbot/externalLinkInfo?dbname=dewiki@WMF&pageid=9301140&lang=de
     werden als HTML-Dokument in Form einer Liste <ul> alle URL und die ggf. zugehörigen Erkenntnisse präsentiert.
   • Ein Steuerparameter regelt explizit, ob alle URL oder nur diejenigen mit Erkenntnissen gezeigt werden sollen; wenn nicht angegeben, dann nur diejenigen mit Erkenntnissen. Regelfall für „Erkenntnisse“ wäre die vermutete Nichterreichbarkeit.
   • Ggf. wäre nach Domain und Pfad zu sortieren: die Domain nach TLD, 2nd level, 3rd level usw.; port, http/https; Pfad.
   • Die Präsentation sollte auch in der Testphase schon wählbar deutsch/englisch erfolgen; ansonsten nur englisch, damit das Mock-Up international als Grundlage für eine Neuentwicklung durch WMF dienen kann und auf anderen Wikis probehalber eingesetzt werden könnte. Vorgabe ist deshalb englisch.
   • Die Verlinkung ist geeignet, den Seiteninformationen jedes Artikels hinzugefügt zu werden.
3. Interaktives Formular
   • Das Ergebnis ist genau die gleiche HTML-Präsentation.
   • Hinzu kommt ein Formular zur Auswahl des Wikis, des Seitennamens oder der pageid, des Anzeigeumfangs und der Sprache.
   • Über die URL können die Formularfelder vorbelegt werden.
   • Das interaktive Formular kann auch Antwort auf die Anfrage nach einer durch URL-Parameter bereits spezifizierten gezielten Auswertung sein, die danach vom Leser modfiziert werden kann.
4. Weiteres API-Format
   • Bei Bedarf könnte für andere Software ein weiteres automatisch auslesbares Format mit den gleichen Informationen wie unter 1 und 2 hilfreich werden.
   • In Frage kämen JSON, das identisch mit dem Kernstück von 1 ist; oder XML, das weitgehend identisch mit dem Kernstück von 2 wäre (jedoch mit anderen Elementnamen).
   • Es empfiehlt sich also für beide Implementierungen eine offene Programmierung der eigentlichen Datenformatierung, die Mehrfachnutzung des Codes ermöglicht.