XML Beschreibung

[dibe]

Danke,
ähnlich hat unser ältester Entwickler auch argumentiert.
Alles, bis zu einem best. Punkt in einen String einlesen, auswerten und den String nachladen(oder so ähnlich).
Dachte nur, das es (grade weil ja fast jeder CAMT verarbeitet) das es da was einfacheres mit den öfter erwähnten Bordmitteln im RPG gibt. Nur hat bei uns damit noch keiner gearbeitet.
DiBe

[AG1965_2]

Prinzipiell stimme ich zu, dass man "bloß wegen XML" nicht gleich auf eine andere Sprache umsteigen muss.
Aber das Spitze-Klammern-Suchen sollte man wirklich XML-SAX überlassen.
Denn der kann mit Kommentaren, Referenzen, CDATA
usw. auch umgehen, was viele selbstgebastelte Lösungen schlicht vergessen, weil es in den Beispiel-XMLs nicht vorkam.
Warum sollte man ein perfekt rundes Rad nicht benutzen und stattdessen ein eckiges nehmen?
Keine Angst, es bleibt noch genug über zum Selbermachen.

[camouflage]

... oder wenn V7R1 im Einsatz ist, kann man auch die Funktionen des SQL verwenden. Insofern sollte man sich schon mit den neusten Features auf der Power i auseinander setzen, ansonsten wirklich ein gleiches Ende wie jenes der Dinos droht. TR8 ist nämlich schon angedroht!

[BenderD]

Prinzipiell stimme ich zu, dass man "bloß wegen XML" nicht gleich auf eine andere Sprache umsteigen muss.

... hat das irgendjemand empfohlen? Ich habe halt mehrere Programmiersprachen zur Auswahl und nehme am liebsten die, die mir da die beste Unterstützung bietet - und das ist bei XML nicht gerade RPG und auch nicht SQL. Beim abbilden von geschachtelten Strukturen sind Objekt orientierte Sprachen da klar im Vorteil.

D*B,
der gerade an die deutsche Eiche und Schwarzwild denkt...

[AG1965_2]

Auch die Rinde einer Eiche hält nicht ewig, wenn sich nur genug Wildschweine dran reiben. :-)

[Robi]

Hallo,
ich klinke mich hier mal ein, da ich nun auch CAMT einlesen muß.
Soweit meine momentane Recherche richtig ist, muß ich sowohl bei XML-Into als auch bei SAX wissen, was in dem XML für Felder kommen. Ich kann zwar allowmissing / allowextra setzen, das führt jedoch dazu, das die Verarbeitung bei einem Fehler (fehlendes / zuviel Element(e)) beendet wird.
(ist für mich zwar unlogisch, aber gut, die Verwendung von XML an sich ist für mich auch nicht 'Die Ideale Schnittstelle'. Vermutlich habe ich irgend etwas noch nicht verstanden.)

Alle Beispiele die ich gefunden habe 'kennen' das XML-Dokument.
Von der Bank haben wir die Info, das 'natürlich' nicht jedes Feld in jedem 'Datensatz' eines jeden Kontoauszuges vorkommt.
Damit hab ich nun ein Problem.
Wie löst Ihr das?
Leider habe ich bisher auch kein vernünftiges(komplexes) BSP für einen Sax-Hander gefunden.
Selber Parsen kommt hier nicht in Frage, Java verwenden auch nicht.

Danke für weitere Tips,

Robi

[Fuerchau]

Da nun mal die XML-Integration in RPG nur mehr rudimentär ist, kommst du bei solchen Schnittstellen um Sprachen, die XML vollständig unterstützten leider nicht drum rum.
Wenn Java oder selber parsen nichts ist, musst du ggf. ein kommerzielles Produkt kaufen.
Beispiel: http://www.goering.de/de/i4xml.html

[andreaspr@aon.at]

Wenn du beim XML-SAX mit einer Handler-Prozedur arbeitest, brauchst du über das XML selbst (theoretisch) überhaupt nichts zu wissen.
Angenommen du willst die Werte für die Tags und haben, so kannst du diese im Handler für jedes Tag welches aktuell verarbeitet wird abfragen und wenn dann das entsprechende Tag "dran kommt" kannst du dessen Wert verarbeiten/speichern.
Dafür musst du z.B. gar nicht wissen wie oft oder wo genau im XML dieses Feld vorkommt.

Natürlich sollte da eine entsprechende Logik dahinter stehen ...
Was passiert wenn das Tag eben öfters vorkommt? Welches wird genommen?
Welche Suchkriterien gibt es? Usw.

[Robi]

Ja, passt, danke

hatte vorher nur berichte von XML-INTO und einem Hander dort drin gelesen und das mit SAX verwechselt.
habe nun dieses Bsp mal übernommen und bei uns debugt. Etwas mehr Klarheit ist nun da.
Jetzt werde ich mir die CAMT Beschreinbung mal ansehn .

[BenderD]

Hallo,
ich klinke mich hier mal ein, da ich nun auch CAMT einlesen muß.
Soweit meine momentane Recherche richtig ist, muß ich sowohl bei XML-Into als auch bei SAX wissen, was in dem XML für Felder kommen. Ich kann zwar allowmissing / allowextra setzen, das führt jedoch dazu, das die Verarbeitung bei einem Fehler (fehlendes / zuviel Element(e)) beendet wird.
(ist für mich zwar unlogisch, aber gut, die Verwendung von XML an sich ist für mich auch nicht 'Die Ideale Schnittstelle'. Vermutlich habe ich irgend etwas noch nicht verstanden.)

Alle Beispiele die ich gefunden habe 'kennen' das XML-Dokument.
Von der Bank haben wir die Info, das 'natürlich' nicht jedes Feld in jedem 'Datensatz' eines jeden Kontoauszuges vorkommt.
Damit hab ich nun ein Problem.
Wie löst Ihr das?
Leider habe ich bisher auch kein vernünftiges(komplexes) BSP für einen Sax-Hander gefunden.
Selber Parsen kommt hier nicht in Frage, Java verwenden auch nicht.

Danke für weitere Tips,

Robi

... das Problem ist, dass es da eine Beschreibung des Datensatzes gibt, die selber wieder in XML abgefasst ist. Da gibt es halt Komponenten mit unterschiedlicher Qualität, die unterschiedlich Geld kosten könnten (was nicht mit Qualität korelliert sein muss). Für blankes RPG gibt es da nur die bereits benannten Bordmittel (oder den EXPAT Parser). Da die alle nicht validieren, muss man die Validierung selber programmieren; da zu gehört nicht nur, dass alle Muss Komponenten da sind und keine Komponenten drin sind, die nicht definiert sind - fataler sind Störungen in der Struktur (fehlendes Ende Tag, oder fehlender Knoten), da kann selbstgestricktes schon mal gerne in den Wald rennen und sich dort verirren! Natürlich kann man das auch alles zu Fuss programmieren (wie in diesem Thread ja bereits empfohlen), aber zuweilen sind diese "Räder" an Stellen eckig, an denen fertige guter Qualität rund laufen.

D*B

[AG1965_2]

Ich habe es mir zwar angetan, xsds zu lesen (mit XML-SAX) um meinen Kolleginnen ein Framework zum einfacheren Lesen und Schreiben von darauf basierenden XML-Dateien zu basteln, aber einen Validator - nein, das verweigere ich und sollte jeder (RPG-)Programmierer verweigern.

Das gibt's gratis fertig, das darf auch gern in Java programmiert sein, z.B. Xerces lässt sich ganz gut verwenden.

Und nur wenn der validierende Parser zufrieden ist, geht man dann mit dem RPG ran. Ansonsten mit Fehlermeldung zurück zum Absender.

Die RPG-XML-Operationscodes prüfen nur das, was sie selber dringend zum Überleben brauchen.

Und um Probleme wie gleichnamige Elemente/Attribute mit verschiedener Bedeutung zu lösen, kommt man um den kompletten "Pfad" nicht herum. Beim Start des Elements / Attributs kommt der Name mit einem / hinten an den Pfad-String dran, beim Ende wieder weg.
Dann hat man z.B. /Customer/Id und /Supplier/Id, auf die man seine Programmfelder "mappen" muss, und hat kein Problem mehr.

[BenderD]

Und nur wenn der validierende Parser zufrieden ist, geht man dann mit dem RPG ran. Ansonsten mit Fehlermeldung zurück zum Absender.

... bleibt nur die Frage übrig, warum man das dann nicht komplett in Java z.B: in eine Datenbank packt und sich das restliche XML Geschäft in RPG erspart...

D*B