Delphi-PRAXiS
Seite 2 von 3     12 3      

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   XML (https://www.delphipraxis.net/46-xml/)
-   -   Delphi Argumente für XML gesucht (https://www.delphipraxis.net/89206-argumente-fuer-xml-gesucht.html)

Elvis 27. Mär 2007 15:31

Re: Argumente für XML gesucht
 
Zitat:

Zitat von Catbytes
Das Zeugs ist fast alles ISO genormt, bzw. es stehen die führenden großen Konzerne von Deutschland hintendran (Heiler, Oracle, IBM, SAP etc.).

Weil es pille-palle ist, sich ein Schema für die eigenen Daten zu basteln, um sie spezifisch vaidieren zu können.
Und ja man kann auch ein eigenes Schema und das BMEcat nehmen, sozusagen ein Subset oder ein Superset eines bestehenden, xml-basierten Dokumententyps bauen.
Die binären Formate kann man getrost ignorieren, zur Not kann man sich eine Transformation (XSL) schreiben, die die XML in eines der vorgeschlagenen, proprietären Blablaformate überträgt.

Bernhard Geyer 27. Mär 2007 15:32

Re: Argumente für XML gesucht
 
Das dumme an solchen Standards ist das es für jede Sache immer mindestens 2 gibt.
Deshalb möchte ich auch noch IDOC ins rennen schmeißen.

Catbytes 27. Mär 2007 16:23

Re: Argumente für XML gesucht
 
Zitat:

Zitat von Elvis
Und ja man kann auch ein eigenes Schema und das BMEcat nehmen, sozusagen ein Subset oder ein Superset eines bestehenden, xml-basierten Dokumententyps bauen.

Stimmt. Das kann man. Muss man aber nicht. Per USER_DEFINED_EXTENSIONS in BMEcat kann man so ziemlich alles unterbringen und ist noch im Standard.

Allerdings: Einen Nachteil will ich an den ganzen Normen nicht verschweigen. Nahezu jeder Lieferant/Kunde hat so seine eigenen Vorstellungen, was "genormt" bedeuted. Da wird aus einem Kann-Feld ganz schnell ein Muss-Feld und/oder umgekehrt.

Hier in der Firma habe ich bestimmt 20 solcher "Standards" auf der Platte liegen...

Wenn es um Onlineanbidung in Verbindung mit SAP geht, schmeisse ich mal noch den EBP* in die Runde (SAP -> EBP -> Shop -> EBP -> SAP).

*EBP = Enterprise Buyer Professional ist eine E-Procurement-Komponente zum Strategic Sourcing innerhalb von mySAP SRM: Er stößt beispielsweise Freigaben, Bestellungen, Waren- und Rechnungseingänge an

Alexander 27. Mär 2007 19:04

Re: Argumente für XML gesucht
 
Zitat:

Zitat von mschaefer
PS: Einen haken hat XML-aber noch. Es reagiert etwas empfindlich auf Sonderzeichen (Umlaute, Symbole, Eurozeichen),
deshalb verwenden wir oft eine Base64 kodierung für die Nutzdaten. Damit ist das natürlich mit Notepad nichts mehr zum kontrollieren.

Die Probleme mit den Umlauten etc. halten sich auch in Grenzen. Beim De-/Serialisieren unter .NET wird das z.B. automatisch umgewandelt. Unter VCL wird es vermutlich ähnliches geben.
Und sonst gibt es noch CDATA-Abschnitte.

mschaefer 27. Mär 2007 19:17

Re: Argumente für XML gesucht
 
Ja gerade die Wandlung der VCL hat mich zu der Base64-Codierung gebracht!
Damit sind auch sämtliche anderen Sonderzeichen erledigt.

PS: Die Codierung kann ich wahlweise zuschalten, aber die Erfahrung zeigt halt, eingeschaltet gibt es keine Probleme damit.

Grüße // Martin

Bernhard Geyer 27. Mär 2007 21:52

Re: Argumente für XML gesucht
 
Zitat:

Zitat von mschaefer
Ja gerade die Wandlung der VCL hat mich zu der Base64-Codierung gebracht!
Damit sind auch sämtliche anderen Sonderzeichen erledigt.

Vermutlich hat dies mit autoamtischen Wandlungen String/Widestring bei vielen Komponeten zu tun. Bei guter und sauberer Programmierung der XML-Komponenten und entsprechender Kapslung gibt es damit keine Probleme!

yankee 27. Mär 2007 22:10

Re: Argumente für XML gesucht
 
tsss... Da denkt man mitsamt xml kommt Unicode und stattdessen nehmen die Leuts einfach base64_encode...
Warum nehmt ihr dann nicht gleich binäre Dateien? Ihr schmeisst doch einen Teil des xml-Vorteils über board!

shmia 28. Mär 2007 09:14

Re: Argumente für XML gesucht
 
Vielen Dank für die Antworten; ich fasse meine Argumente hier mal zusammen:
Zitat:

1.) hierarchische Beziehungen können in beliebiger Tiefe abgebildet werden
2.) Daten werden strukturiert gespeichert. Es ist sofort klar, welche Daten zusammengehören.
3.) Daten können im UNICODE Zeichensatz übermittelt werden
4.) Das Format ist weitgehend selbstbeschreibend. Änderungen/Erweiterungen werden von allen beteiligten Stellen sofort verstanden, ohne dass dies über eine zusäzliche Dokumentation erklärt werden müsste.
5.) XML ist ein "offener Standard" des W3C (World Wide Web Consortium). Daher ist meist schon ein reiches Instrumentarium zur Verarbeitung vorhanden
6.) XML kann über XSLT in andere Formate (z.B. HTML, PDF, CSV, ...) transformiert werden
7.) Zukunftssicher. Alle grossen Softwareunternehmen setzen auf XML
8.) XML kann über Cascading Style Sheets oder XSL in gut lesbarer Form in einem Webbrowser dargestellt werden.
Zum Thema Codierung: ich werde einfach die MSXML ActiveX Library verwenden.
Somit brauche ich mir mit Parsen und Codieren nicht die "Finger schmutzig machen".

Bernhard Geyer 28. Mär 2007 09:26

Re: Argumente für XML gesucht
 
zu 4: Schon mal probiert eine XML zu verstehen ohne Doku's zu haben. Mit richtiger Dokumentation ist es einfacher.
Erweiterungen werden nicht sofort von allen Stellen verstanden, jedoch verursachen solche Erweiterung (neue Attribute/Keys) keine größeren probleme wenn diese keine zwingend nötigen Elemente sind und die XML-Einleseroutine der Anwendungen nicht fehlerhaft sind (Also die Regeln von guten Parsern/Leseroutinen einhält).

zu 5: XML ansich ist Standardisiert. Jedoch wird man bei manchen Realisierungen (BMECat oder ähnlichen) kostenpflichtiges Mitglied in dem entsprechenden Standardisierungskremium sein und nötige Dokumentation oder Hilfe zu bekommen.

Elvis 28. Mär 2007 10:47

Re: Argumente für XML gesucht
 
Zitat:

Zitat von shmia
Vielen Dank für die Antworten; ich fasse meine Argumente hier mal zusammen:

Das wichtigste hast du vergessen: "Einfache Validierbarkeit"


Alle Zeitangaben in WEZ +1. Es ist jetzt 00:49 Uhr.
Seite 2 von 3     12 3      

Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz