View Full Version : XML Beschreibung
Ja, passt, danke
hatte vorher nur berichte von XML-INTO und einem Hander dort drin gelesen und das mit SAX verwechselt.
habe nun dieses (http://www.mcpressonline.com/programming/rpg/rpg-has-sax-appeal.html) Bsp mal übernommen und bei uns debugt. Etwas mehr Klarheit ist nun da.
Jetzt werde ich mir die CAMT Beschreinbung mal ansehn .
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
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.
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
Das ist recht einfach zu erklären: relativ viele RPG-ProgrammiererInnen, relativ wenige Java-ProgrammiererInnen.
Prämisse für solche wichtigen Dinge ist, dass möglichst viele MitarbeiterInnen sie verstehen können müssen. Darum RPG.
... schwaches Argument:
- jeder neue Programmierer hat Java Kenntnisse
- nur die wenigsten RPG Programmierer haben jemals call back und ähnliches gesehen
- Java Programme sind bei gleichem Niveau des Programmierers besser lesbar als RPG Programme
=> hier wird der direkten Produktion vob Altlasten das Wort geredet, und lass mich raten: auf die Validierung wird dann in 9 von 10 Fällen auch noch verzichtet, nach dem Motto: nur Mut, wird schon gut gehen - und wenn da jemand Scheiß schickt, dann ist der ja schließlich dran schuld, wenns bei mir knallt!
D*B
camouflage
24-04-14, 17:34
Ha, vielleicht ist Pascal Polverini ja Erfolg beschieden, wenn er an der Common in Florida der IBM seinen Vorschlag, XML anstelle der DDS zu verwenden, abgibt. Ich glaube allerdings nicht daran.
Allerdings kann sich ja jeder einen XML Open Access Handler selber schreiben. *fg
...das wäre ja aberwitzig: standardisierte SQL DDL durch ein dafür untaugliches Konstrukt zu ersetzen (das könnte ja für die AS/400 Clientel ein Argument sein, aber da gibt es ja nix an Software Altlasten zu receyceln, wie bei dem Rohrkrepierer PCML...). BTW: das mit der Totgeburt OA würde ja an der Validierungs Problematik nix ändern...
D*B
Also wir finden immer wieder RPG-Programmierer, die mit Java überhaupt nichts am Hut haben.
Es gibt auch ganz frisch ausgebildete, die "nur" RPG drauf haben; meine jüngste Kollegin ist z.B. gerade mal 17 Jahre alt.
Das Verhältnis RPG : Java ist mindestens 10 : 1.
Mittlerweile habe ich 2 Programmierern mit mehr oder minder grauen Haaren das Callback-Prinzip erklärt und sie wenden es auch an. Weil es ihnen Arbeit abnimmt und besser funktioniert als ihre bisherigen Lösungen.
Wenn wir uns alle das wünschen, gibt's vielleicht auch mal einen Validator / validierenden Parser, den man auch aus der klassischen Welt einfach nutzen kann.