XML-Technologien

XML-Technologien

Posts 1-10 of 13
  • Frank Bueltge
    Frank Bueltge
    The company name is only visible to registered members.
    XML Ausprägung; Hilfe gesucht
    Hallo zusammen,
    ich habe im Unternehmen eine Schnittstelle entwickelt, die viele Applikationen bedient und als zentrales Format steht. Nun fangen die ersten Anwender an und möchten dieses Format als zentrales Format des Unternehmens sehen - was ich begrüße und immer als Ziel hatte. Viele Anwender sind in kleinen Scripten zu Hause und erstellen sich mittels Python u.ä. Ausgaben von Berechnungen u.ä. Dabei wird in der Regle mit Bibliotheken zum Arbeiten mit XML gearbeitet und alle diese Bibliotheken sind so aufgebaut, dass man ein Tag sucht und den Inhalt zurück gibt bzw. ein Tag mit Wert übergibt um XML zu schreiben.

    Mein Format ist "Inhaltsbasierend" - der Transporter, das Format interessiert sich nicht für den Tag, der Tag beschreibt nicht, was es ist. Zum besseren Verständnis ein Beispiel, welches vereinfacht ist, keine Attribute enthält und ebenso den head weg lässt.

    "tagbasierendes" XML
    <lens>
    <radius>1.0</radius>
    <thickness>20.0</thickness>
    </lens>

    "inhaltsbasierendes" XML
    <PropertyValuation>
    <PropertyReference>lens</PropertyReference>
    <ValueGroup>
    <ID>1</ID>
    </ValueGroup>
    <PropertyValuation>
    <PropertyReference>radius></PropertyReference>
    <ValueGroup>
    <ID>2</ID>
    <PartentID>1</ParentID>
    <PropertyValue>1.0</PropertyValue>
    </ValueGroup>
    </PropertyValuation>
    <PropertyValuation>
    <PropertyReference>thickness</PropertyReference>
    <ValueGroup>
    <ID>3</ID>
    <PartentID>1</ParentID>
    <PropertyValue>20.0</PropertyValue>
    </ValueGroup>
    </PropertyValuation>
    </PropertyValuation>


    In beiden Fällen ist das gleiche an Inhalt drin, im zweiten Fall muss ich den Transporter, das Format, nie anfassen. Ich kann validieren und wohlgeformtheit prüfen.
    Aber man kann nicht mit klassischen Mitteln via Bibliothek auf die Werte sofort zugreifen, man muss nach der Rückgabe eigene Schleifen schreiben, die den Wert zurück geben.
    Für mich war wichtig, dass der Transporter jede Art von Inhalt transportieren kann und dass ich keine Zoo von Tags verwalten muss, da die Merkmale (im ersten Fall also die Tags; im zweiten Formatbsp. der Inhalt) sich stetig erweitern können.

    Nun aber zu meinem Problem.
    Ich diskutiere nun schon viel und lange, kann aber nicht stichhaltig belegen, dass mein Ansatz besser ist. Kann mir jemand Gründe liefern, hat jemand mit dieser Art der Diskussion Erfahrung?
    Die Aussage, dass man Inhalt und Layout trennt, genügt hier nicht - ich brauche mehr Punkte als die Idee, die Philosophie dahinter. Wir haben bereits auf Code-Ebene verglichen und in jedem Punkt ist man immer wieder, es gibt auf beiden Seiten Vor- und Nachteile und trotzdem suche ich Punkte, die das inhaltsbasierende Format bestätigen. Viele Unternehmen nutzen es, Microsoft, SAP und Google sind nur einige Vertreter - aber ich finde keine stichhaltigen Grüne warum.

    VIELEN DANK für die Mühe, die Zeit und eventuell eine Antwort.
    • 12 May 2010, 09:04 am
  • Post visible to registered members
  • Frank Bueltge
    Frank Bueltge
    The company name is only visible to registered members.
    Re^2: XML Ausprägung; Hilfe gesucht
    Vielen Dank für die Antwort.

    Ja, man kann die Formate transformieren, was aber einen neuen Aufwand generiert und mit jedem neuem tag aus dem ersten Bsp. muss ich die Transformation anfassen.
    Ich bin natürlich interessiert, dass man sich auf ein Format einigt, da so der Austausch im gesamten Unternehmen leichter fällt und die Fehlerquelle der Transformation weg fällt.
    • 12 May 2010, 10:00 am
  • Stefan Gentz
    Stefan Gentz    Premium Member   Group moderator
    The company name is only visible to registered members.
    Re: XML Ausprägung; Hilfe gesucht
    Beide Modelle haben ihren Charme. Im Sinne von KISS (Keep it smart and simple) ist wohl das erste Beispiel ansprechender, weil "menschenlesbarer" und schneller erfassbar. Aber wie Sie schon ganz richtig festgestellt haben, führt dies bei zunehmender Daten-Komplexität ganz schnell zu einem "Zoo" von Tags was letztlich auch zum Kostentreiber werden kann (allein schon, weil sich der Dokumentationsaufwand (DTD/Schema) erhöht).

    Das zweite Beispiel erscheint dagegen ein bisschen wie "mit Kanonen auf Spatzen geschossen" und sieht erstmal nach "warum einfach, wenn's auch kompliziert geht?" aus. Tatsächlich ist es aber natürlich ganz klar die einfachere und nicht die kompliziertere Variante (von möglichen Mehraufwänden bei der Programmierung von Abfragen mal abgesehen, wobei ich das zumindest aus XSLT-/XPATH-Sicht nicht sooo problematisch finde), weil sie neutraler und dadurch flexibler einsetzbar ist.

    Vielleicht wäre es ein Ansatz, beide Welten miteinander zu kombinieren, und einen neutralen Transporter zu formulieren, der dennoch einfach abfragbar und menschenlesbar bleibt, z.B. etwas in der Art:

    <property>
    <propertyvalue type="radius">1.0</propertyvalue>
    <propertyvalue type="thikness">20.0</propertyvalue>
    </property>

    Das sind nur zwei Elemente (property, propertyvalue), ist "menschenlesbar" und sofort verständlich, bleibt durch die Attribute schön flexibel, und ist wunderbar einfach abfragbar.
    This post was modified on 12 May 2010 at 10:41 am.
    • 12 May 2010, 10:38 am
  • Frank Bueltge
    Frank Bueltge
    The company name is only visible to registered members.
    Re^2: XML Ausprägung; Hilfe gesucht
    Eine spannende Idee.
    Aktuell händel ich ca. 20.000 Merkmale, die dann Attribute oder Tags wären. Täglich kommen neue hinzu. Das Thema ist komplex, die Merkmale sind von Definitionen abhängig und unterliegen einem Normungsprozess - wir übergeben dann GUIDs, damit es eindeutig ist. Das Lesen der XMLs ist so gut wie nie nötig. Es ist in beiden Fällen schwer, auch wenn Variante 1 erst mal einfacher erscheint, wenn ich aber bspw. FEM-Daten übergebe, dann rede ich hier von ca. 1.500.000 Daten - da wird es eh schwer mit dem menschl. Auge zu lesen - ich arbeite hier immer mit Hilfe der Maschine.
    Aktuell sehe ich die Chance für das "inhaltsbasierende" Format darin, dass ich recht flexibel erweitern kann. Dem Merkmal Breite gebe ich andere Merkmale mit um so bspw. die Einheit etc. zu definieren.
    • 12 May 2010, 10:58 am
  • Post visible to registered members
  • Frank Bueltge
    Frank Bueltge
    The company name is only visible to registered members.
    Re^2: XML Ausprägung; Hilfe gesucht
    Das erste Format muss mit dem Merkmalen wachsen, neues Merkmal heißt sofort neuer Tag. Dies ist im zweiten Fall nicht nötig. Die Möglichkeiten sind offen, das Format ändert sich so gut wie nie und trotzdem kann man unabhängig voneinander neue Inhalte transportieren. Es sind untersch. Bereiche betroffen und def. unabhängig voneinander neue Inhalte. Validieren wollen aber alle.

    Warum nutzt so gut wie jede größe Applikation dieses Format: in meinen Augen wegen der Verwaltung der Tags und der damit verbundenen Kompatibilität über die Zeit. Schaut man sich bspw. docx an und entpackt es, dann steckt genau das darin. Bei einem XML eines RSS-Feed ändert sich so gut wie nichts, da ist ein Tagbasierendes toll, wenn ich aber die Inhalte frei steuern will, dann sehe ich den großen Vorteil in einem inhaltsbasierenden Container, der seinen Inhalt nicht kennen muss. Validieren tue ich im übrigen durch ein weiteres XML, was sagt, was sein darf und was nicht.

    Die Vor- und Nachteile, die ich sehe:
    Trennung zwischen Inhalt und Layout
    Inhalt trägt die Information
    Layout sorgt für die Zugänglichkeit des Inhalt
    - Applikationsunabhängigkeit
    - Transporterunabhängigkeit vom Inhalt
    - Aufbereitung für verschiedene Applikationen/Endgeräte
    - Nutzung eines universellen Transporterformates
    - Unabhängig vom Inhalt und „überlebensfähig“
    - Kosten: Lesbarkeit des Formates durch den Menschen erschwert bzw. mit Tools möglich


    Bsp. MS Word:
    ich transportiere Inhalt, diesen muss ich als Anwender strukturieren, die Gegenseite muss diesen verstehen können
    das Format selber ist für den Anwender egal, der Computer muss es zuverlässig verstehen können
    ich möchte bei einer Erweiterung meines Inhalts nicht das Word-Programm patchen müssen, sondern ich lese neue Inhalte ein, die ich ggf. neu verstehen können muss, wen es nicht interessiert, der soll sich dadurch nicht beeinträchtigt vorkommen
    • 12 May 2010, 12:16 pm
  • Post visible to registered members
  • Post visible to registered members
  • Erik Pöhler
    Erik Pöhler
    The company name is only visible to registered members.
    Re^5: XML Ausprägung; Hilfe gesucht
    inhaltsbasiert, tagbasiert... attributbasiert fehlt hier noch in den alternativen, denn das machts tatsächlich nochmal knapper. und was die lesbarkeit/zugänglichkeit betrifft, kann man auch bei möglichst knappen element- und attributnamen immernoch ne legende in kommentare packen im XML, im XSL, in den Klassen.

    mein vorschlag (wobei man item auch nur i nennen könnte um das ganze nochmal zu kürzen). die einheit mitzuspeichern finde ich unsinnig, könnte man nicht durch eine konvention lösen? umgerechnet ist sowas doch flink in einer methode

    <root>
    <item k="radius" u="in" v="1" />
    <item k="thickness" u="in" v="20" />
    </r>
    • 14 May 2010, 1:23 pm