XML-Best Practices: Planen der Erweiterbarkeit

Question

Ich bin gerade dabei, ein XML-Format zu erstellen. Ich habe große Ideen, wo ich das hin möchte, aber am Anfang möchte ich klein anfangen und Erweiterbarkeit erlauben. Ich habe viel über das Thema XML-Attribute vs. XML-Elemente gelesen, wann sie zu verwenden sind, Vor-/Nachteile von beiden usw. Der allgemeine Konsens (siehe here und here) scheint zu sein, wenn möglich XML-Elemente zu verwenden Sie sind absolut sicher, dass ein Teil der Daten atomar ist und niemals erweitert werden müsste oder wirklich Metadaten über die Behandlung eines Elements sind.

Also hier ist meine Frage. Sagen wir, ich folge dieser Anleitung und erstelle ein einfaches XML-Dokument wie dieses.

<person> 
    <name>John Doe</name> 
</person> 

Ich habe, was ich dachte, war Best Practice. Dies ist die grundlegendste Form, die momentan funktioniert, und ich habe die Daten in ein Element gegen ein Attribut platziert, falls ich es später erweitern möchte. Nehmen wir an, ich benutze dieses Format seit einiger Zeit und möchte es erweitern. Wie mache ich das, ohne einen bestehenden Prozess zu unterbrechen, der einen vollständigen Namen im Text des Namenselements erwartet?

Wenn ich es so erweitert.

<person> 
    <name>John Doe 
     <firstname>John</firstname> 
     <lastname>Doe</lastname> 
     <alias>John Doe</alias> 
    </name> 
</person> 

Es würde brechen Prozess bestehende, weil jetzt der Innertext von ‚name‘ sein „John Doe DoeJohnDoeJohn“ wird. Ich weiß, dass es Möglichkeiten gibt, damit umzugehen, aber der Punkt ist, bestehende Dinge nicht zu brechen, die erwarten, dass der innere Text den vollständigen Namen enthält.

Die einzige Möglichkeit, die ich leicht erweitern kann, ist, die neuen Werte Attribute von 'Name' zu machen. Was aber, wenn ich zusätzliche Komplexität wollte? Wie mehrere "Alias" -Werte. Mit Attributen wäre das nicht möglich.

Es scheint, als wäre die einzige Möglichkeit, dies zu erweitern, ohne den bestehenden Prozess zu unterbrechen, die Auswahl eines neuen Elementnamens.

<person> 
    <name>John Doe</name> 
    <extendedname> 
     <firstname>John</firstname> 
     <lastname>Doe</lastname> 
     <alias>John Doe</alias> 
     <alias>Jon Doe</alias> 
    </extendedname> 
</person> 

So würde das funktionieren und mein Problem lösen, aber ich bin frage mich, „warum genau es für‚Name‘wichtig war, ein Element zu sein, anstelle eines Attributs?“ Es kommt mir irgendwie so vor, als ob es am Ende egal wäre, ob 'name' ein Attribut von 'person' oder ein Kindelement mit inertext ist, weil ich am Ende nur einen neuen Elementnamen verwenden musste.

Es fällt mir auf, dass ein hybrider Ansatz wie dieser am flexibelsten wäre und maximale Erweiterbarkeit zulässt, aber ich konnte nicht wirklich ein Beispiel dafür finden, dass jemand dies tut. Wenn Sie damit angefangen haben ...

Es könnte leicht in diese umwandeln, ohne bestehende Prozesse zu brechen und noch für weitere Erweiterung ermöglicht.

<person> 
    <name value="John Doe" /> 
     <firstname value="John" /> 
     <lastname value="Doe" /> 
     <alias value="John Doe" /> 
     <alias value="Jon Doe" /> 
    </name> 
</person> 

Es scheint Art von mir, wie die Führung Verwendung Elemente sein sollte, wo möglich und stellen Sie die Werte innerhalb einer Art von ‚Wert‘ Attribute im Tag. Und wie immer sollte der gesunde Menschenverstand gelten und Sie sollten den internen Text verwenden, wenn dies angemessen ist, wie eine Nachricht, ein Memo oder ein Notizfeld.

Kann ich ein kritisches Designelement im ersten Beispiel nicht verstehen, das macht einen besseren Ansatz? Hat jemand die Erfahrung gemacht, dass ein XML-Schema erweitert werden muss, während die umgekehrte Kompatibilität beibehalten wird und die gleichen Probleme oder Lösungen hier auftreten? Jede Anleitung oder Profi-Tipps wären willkommen.

Answer 1

Unter der Annahme, dass Sie Ihre Parser bauen auf früheren Releases' Container-Elemente zu erkennen, können Sie dies tun:

<doc xmlns:v1="http://example.com/yourformat/1.0" 
    xmlns:v2="http://example.com/yourformat/2.0"> 
    <v1:person> 
    <v1:name>John Doe</v1:name> 
    <v2:name> 
     <v2:firstname>John</v2:firstname> 
     <v2:lastname>Doe</v2:lastname> 
     <v2:alias>John Doe</v2:alias> 
     <v2:alias>Jon Doe</v2:alias> 
    </v2:name> 
    </v1:person> 
</doc> 

Offensichtlich machen v2 die Standard xmlns wenn Sie nicht alle Präfixe gefällt.

---

Auf diese Weise, auch mit v2 Inhalt hinzugefügt, ist das Dokument weiterhin volle Gültigkeit zu einem v1 Parser.