Gute oder gebräuchliche Namenskonventionen für XML-Namespace-URIs

Question

Ich bin auf der Suche nach ein paar Ideen für gute Namenskonventionen für xsd-Zielnamespaces.

Grundsätzlich muss ich nur eine definitive Entscheidung treffen, wie ich den Ziel-Namespace meines xsd benennen soll, damit ich es beim ersten Mal richtig mache. Ein späteres Ändern würde Änderungen an einem anderen System erfordern, das nicht unter meiner Kontrolle steht.

Haben Sie Erfahrung mit früheren XML-Schemakreationen, was ist eine gute und funktionierende Lösung? Ich habe versucht, Informationen online zu finden, aber die meisten Beispiele verwenden nur sehr allgemeine Zielnamespaces wie "http: // exampleSchema" und ähnliches. Ich versuche tatsächlich, einige Beispiele aus dem wirklichen Leben zu finden.

Answer 1

W3Cs eigene Methoden für die langlebige URI-Auswahl sind eine ziemlich gute Basis für XML-Namespace-URIs. Einige Vorschläge finden Sie unter Cool URIs don't change, mit der Ausnahme, dass ein Namespace-URI nicht abrufbar ist und einige dieser Richtlinien möglicherweise nicht zutreffen.

• einen Präfix verwenden, die die Spezifikation Eigentümer wie die URI des Web-Servers eindeutig gebunden ist. Wenn das Schema online verfügbar sein wird, ist es eine nette Geste, wenn es unter seiner Benennungs-URI gefunden werden kann. Die Verwendung von HTTP-URLs ist nicht erforderlich, obwohl dies gängige Praxis ist.
• Fügen Sie ein ungefähres Datum in die Nähe von (Jahr und Monat ist gut) ein, damit, wenn Sie Ihren Namensraum in Zukunft neu organisieren, der Jahrgang des Namens (und damit seine interne Organisation) eindeutig ist. Beachten Sie, dass dies das Datum ist, an dem der URI zuerst zugewiesen wurde, nicht das Datum der aktuellen Version.
• Fügen Sie einen Namen hinzu, um den Inhalt dieses bestimmten Schemas zu identifizieren, sodass Sie es aus anderen verwandten Schemas ersehen können. Dieser Name sollte unveränderlich sein, auch wenn sich der Marketingname des Betreffenden ändern muss. Vielleicht hat dich jemand anderes überrascht, der ein Markenzeichen trägt, vielleicht versucht die Verkaufsabteilung eine neue Runde, aber der Code sollte nicht kaputt gehen.
• Schließlich, wenn nachfolgende Versionen desselben konzeptionellen Schemas nicht miteinander kompatibel sind, fügen Sie eine eindeutige Versionskomponente hinzu, um die Kompatibilitätsunterbrechung anzuzeigen. Wenn die Versionierung im Rahmen des Vokabulars behandelt wird (z. B. durch ein Versionsattribut), lassen Sie dies nicht zu.

XSLT verwendet die folgenden:

http://www.w3.org/1999/XSL/Transform 

Dies paßt das obige Muster. Eigentümerkennung, Datum und Name; und keine Versionskomponente, da die Versionsverwaltung innerhalb des XSLT-Vokabulars erfolgt.

In einer Prise, können Sie sogar mit

mailto:author@example.org?Subject=2008+XML+Basketweaving+specification 

weg, die auch das Muster passt, sondern schlägt einen Kontaktpunkt anstelle eines Informations-Repository.