1、DEUTSCHE NORMApril 2002Elektronischer Datenaustausch fr Verwaltung, Wirtschaft undTransport (EDIFACT)Teil 4: Regeln zur Auszeichnung von UN/EDIFACT-bertragungsdateien mit der eXtensibleMarkup Language (XML) unter Einsatz von Document Type Definitions (DTDs) 16557-4ICS 35.240.60Electronic data interc
2、hange for administration, commerce and transport(EDIFACT) Part 4: Rules for the markup of UN/EDIFACT interchangeswith the eXtensible Markup Language (XML) using Document TypeDefinitions (DTDs)Echange de donnes informatis pour ladministration, le commerce, et letransport (EDIFACT) Partie 4: Rgles pou
3、r le balisage des changesUN/EDIFACT en utilisant le langage tendu de balisage (XML) mettant enuvre les Dfinitions Type de Document (DTD)VorwortDiese Norm wurde vom Normenausschuss Browesen (NB), Arbeitsausschuss 3 EDI/EDIFACT (NB-AA 3) erarbeitet. Der NB ist u. a. fr normative Festlegungen im Anwend
4、ungsbereich des elektronischenDatenaustausches im weiteren Sinn auch Electronic Commerce zustndig.Die vorliegende Norm ist das Ergebnis eines Normvorhabens der Projektgruppe XML fr ElectronicBusiness des NB-AA 3.DIN 16557, Elektronischer Datenaustausch fr Verwaltung, Wirtschaft und Transport (EDIFAC
5、T), bestehtaus:Gbe Teil 2: Wrterbuch (zz. Entwurf)Gbe Teil 3: Allgemeine Einfhrung fr Einheitliche Nachrichtentypen (UNSMs)Gbe Teil 4: Regeln zur Auszeichnung von UN/EDIFACT-bertragungsdateien mit der eXtensible MarkupLanguage (XML) unter Einsatz von Document Type Definitions (DTDs)Gbe Teil 5: Regel
6、n zur Generierung von XML-Schema-Dateien (XSD) aus EDI(FACT)-Anwendungsbeschreibungen (zz. Entwurf)Fortsetzung Seite 2 bis 14Normenausschuss Browesen (NB) im DIN Deutsches Institut fr Normung e. V. DIN Deutsches Institut fr Normung e.V. .Jede Art der Vervielfltigung, auch auszugsweise, Ref. Nr. DIN
7、16557-4:2002-04nur mit Genehmigung des DIN Deutsches Institut fr Normung e. V., Berlin, gestattet. Preisgr. 09 Vertr.-Nr. 0009Alleinverkauf der Normen durch Beuth Verlag GmbH, 10772 BerlinSeite 2DIN 16557-4:2002-04EinleitungDie rasante Entwicklung im Bereich der Nutzung des Internets fr Electronic C
8、ommerce hat mit dereXtensible Markup Language (XML) einen neuen Hhepunkt erfahren. Am 10. 2. 1998 wurde die Version1.0 dieser Empfehlung vom World Wide Web Consortium (W3C) verffentlicht.XML ist eine Untermenge der Metasprache SGML (Standard Generalized Markup Language, sieheDIN EN 28879:1991) und w
9、urde in erster Linie entwickelt, um ein Instrument zur syntaktischen undsemantischen Strukturierung von Daten im Internet zur Verfgung zu stellen, da die bislang weitgehendverwendete HTML (Hyper Text Markup Language) als Seitenbeschreibungssprache layoutorientiert ist unddiese Fhigkeiten weitgehend
10、vermissen lsst.Sehr schnell wurde erkannt, dass sich mit der Verknpfung von XML zur Beschreibung von Daten und EDIzum Transport von Daten (= XML/EDI) weitere Anwendungsbereiche fr den elektronischenDatenaustausch erffnen. Gerade kleine und mittelstndische Unternehmen (KMU) scheuen oft die nichtunerh
11、eblichen Kosten fr die konventionelle elektronische bertragung ihrer Geschftsdaten, allgemeinbekannt als klassisches EDI. Der Einsatz von mittels XML gestalteten Prozessen im Internet unterVerwendung geeigneter Browser-Software kann diesen Unternehmen einen leichteren undkostengnstigen Einstieg in d
12、ie elektronische Anbindung an Geschftspartner ermglichen.Diese Norm schafft eine Brcke, die es ermglicht, eine UN/EDIFACT-bertragungsdatei eins zu eins aufXML abzubilden und umgekehrt. Damit knnen einerseits bisher geleistete Investitionen in Implementierun-gen auf der Seite der UN/EDIFACT-Anwender
13、weitestgehend gesichert und andererseits neueGeschftspartner, die nicht EDIFACT-fhig sind, mittels der neuen XML-Technologie im elektronischenHandel eingebunden werden.ANMERKUNG Fr diese Norm wurde eine weitestgehend schlanke Lsung angestrebt, um den wirtschaftlichenInteressen nachzukommen. Neuere X
14、ML-Entwicklungen wie z. B. Schemata werden in weiteren Normungsaktivittenbercksichtigt, siehe DIN 16557-5 (zz. Entwurf).1 AnwendungsbereichDiese Norm legt Regeln zur Auszeichnung von UN/EDIFACT-bertragungsstrukturen mit der eXtensibleMarkup Language (XML) unter Einsatz von Document Type Definitions
15、(DTDs) fest. Bei den auszuzeich-nenden Daten handelt es sich um Bewegungsdaten. Diese Norm gilt nicht fr verzeichnisorientierteInformationen wie etwa Status und Wiederholfaktoren sowie implementierungsorientierte Informationen,wie sie gemeinhin in MIGs (Message Implementation Guidelines) zu finden s
16、ind.ANMERKUNG Der Einsatzbereich dieser Norm wird im informativen Anhang B anhand eines Anwendungsszenariosverdeutlicht.2 Begriffe, Symbole und AbkrzungenFr die Anwendung dieser Norm gelten die folgenden Begriffe, Symbole und Abkrzungen:2.1DTD (en: Document Type Definition)Standard-Strukturbeschreib
17、ung eines SGML- und XML-Dokumentes2.2ELEMENTsyntaktischer Baustein, der Daten enthlt und/oder Attribute besitztSeite 3DIN 16557-4:2002-042.3HTML (en: Hyper Text Markup Language)layoutorientierte Seitenbeschreibungssprache2.4NAMEein Name in XML, beginnend mit einem Buchstaben oder einem erlaubten Int
18、erpunktionszeichen, woransich Buchstaben, Ziffern, Bindestriche, Unterstriche, Doppelpunkte oder Punkte anschlieen. Letztere sindals Name-Zeichen bekannt. Namen, die mit xml oder mit einer Zeichenkette beginnen, die zu (X|x)(M|m) (L|l) passt, sind fr die Normung in XML reserviert2.5SGML (en: Standar
19、d Generalized Markup Language)Hochsprache zur Ableitung von Auszeichnungssprachen wie HTML und XML2.6TAGFormatierungsanweisung oder semantische Auszeichnung2.7TemplateSchablonevorgegebenes Referenzmuster, das mit der gesamten zu erkennenden Entitt oder einem ihrer Teileverglichen wird2.8XLL (en: eXt
20、ensible Link Language)Verknpfungssprache zu XML2.9XML (en: eXtensible Markup Language)Auszeichnungssprache u. a. zur Strukturierung von Daten2.10XSL (en: eXtensible Stylesheet Language)Visualisierungssprache zu XML3 Regeln zur Auszeichnung von UN/EDIFACT-bertragungsdateien mitXML/DTDs3.1 Regel 1Der
21、Name im Start- und End-Tag des Wurzelelementes, das die abzubildende UN/EDIFACT-bertragungs-datei umschliet, ist frei whlbar und bezieht sich immer auf einen vollstndigen Interchange. Da einebertragungsdatei unterschiedliche Nachrichtentypen enthalten kann, ist es hierfr nicht sinnvoll, einenUN/EDIF
22、ACT-Nachrichtentyp-Bezeichner zu verwenden.3.2 Regel 2Jedes in der abzubildenden UN/EDIFACT-bertragungsdatei verwendete Segment ist als Subelement desWurzelelements zu definieren. Dies gilt auch fr Service-Segmente und schliet die optionale Trennzei-chen-Vorgabe UNA ein, falls diese verwendet wurde.
23、Seite 4DIN 16557-4:2002-043.3 Regel 3Die Reihenfolge der Segmente innerhalb der abzubildenden UN/EDIFACT-Nachrichten istinnerhalb des Wurzelelements beizubehalten.3.4 Regel 4Der Name im Start- und End-Tag eines Elements unterhalb des Wurzelelements, also der Elementtyp,muss dem UN/EDIFACT-Segmentbez
24、eichner des abzubildenden Segments entsprechen.3.5 Regel 5Der Aufbau des Datenelementnamens folgt der in Tabelle 1 gegebenen Logik.Tabelle 1 Aufbau des Elementnamens fr Datenelementgruppen und DatenelementeStellen Typ Status Inhalt4 an falls vorhanden Bezeichner der UN/EDIFACT-Datenelementgruppem n
25、falls Wiederhol-faktorx-te Wiederholung der Datenelementgruppe im Segment5 an obligatorisch Bezeichner des UN/EDIFACT Datenelements mit vorangestelltem D.m n falls Wiederhol-faktorx-te Wiederholung des Datenelements im Segment bzw. im jeweiligenVorkommen der Datenelementgruppe im Segment3.6 Regel 6F
26、r die Festlegung von Nachrichtentypen knnen External Parameter Entity Declarations verwendet wer-den.Vorschlag fr die Namensvergabe:Gb7 Nachrichtentyp-Bezeichner-6-stelligGb7 Directory-Id.-4- bis 6-stelligANMERKUNG Durch dieses Verfahren knnen Nachrichtentypen in beliebiger Reihenfolge und Anzahl in
27、nerhalbeiner EDIFACT-bertragungsdatei eingesetzt werden.BEISPIEL (Fr den Name der bertragungsdatei wird hier IC verwendet).Seite 5DIN 16557-4:2002-04Im ordersd96a.dtd :Seite 6DIN 16557-4:2002-04Anhang A (informativ)Beispiel fr eine in ein XML/DTD umgesetzte UN/EDIFACT-bertragungsdateiA.1 Zugrunde li
28、egende UN/EDIFACT-bertragungsdateiFr das Beispiel wurde der weit verbreitete und daher bekannte EDIFACT-Nachrichtentyp ORDERS ver-wendet. Um ferner ein in sich abgeschlossenes, konsistentes Dokument zu zeigen, das trotzdembersichtlich bleibt, wurde auer den zwingend vorgeschriebenen Segmenten und Da
29、tenelementen (M =Mandatory) nur ein Minimum an optionalen Segmenten und Datenelementen (C = Conditional) verwendet.BeispielUNB+UNOB:3+SenderElAdr+ReceiverEIAdr+000211:1245+54321UNH+1+ORDERS:D:96A:UNBGM+220+EA1717+9DTM+137:20000217:102NAD+BY+BuyerName+StreetAddress+CityName+12345+xxLIN+1+ProdAX123:SA
30、QTY+21:100UNS+SCNT+2:1UNT+9+1UNZ+1+54321Bild A.1 Nachrichtenaufbau-Diagramm der im Beispiel umzusetzenden UN/EDIFACT-NachrichtSeite 7DIN 16557-4:2002-04A.2 Beispiel fr eine entsprechende DTDDas Beispiel verwendet u. a. den Vorschlag nach Regel 5. Mit den Suffixen (S1, S2, L1) soll gezeigtwerden, wie
31、 angepasste Subsets verwendet werden knnen, ohne in den DTDs den gesamten Nach-richtentyp durchdefinieren zu mssen. Fr den Namen der bertragungsdatei wird hier IC verwendet. DasHaupt-DTD ist in der Datei edifactx1.dtd abgelegt.-Seite 8DIN 16557-4:2002-04Im ordersd96as1.dtd:Seite 9DIN 16557-4:2002-04
32、Seite 10DIN 16557-4:2002-04A.3 Zugehrige XML-DateiUNOB3ReceiverElAdr0002111245543211ORDERSD96AUN220EA1717913720000217102BYBuyerNameStreetAddressCityName12345xx1ProdAX123SA21100Seite 11DIN 16557-4:2002-04S2191154321Seite 12DIN 16557-4:2002-04Anhang B (informativ)Beispiel eines Anwendungsszenarios fr
33、den Einsatzbereich dieserNormDas folgende Beispiel eines Anwendungsszenarios soll den Einsatzbereich dieser Norm verdeutlichen.Zugrunde gelegt wird eine Bestellung, die von einem EDIFACT-Anwender (Kunde) an einen Nicht-EDIFACT-Anwender (Lieferant) bertragen wird. Der nicht EDIFACT-fhige Lieferant an
34、twortet mit einerentsprechenden Rechnung. Der Ablauf gestaltet sich im Einzelnen wie folgt (siehe auch Bild B.1):a) Auf der Seite des Kunden:1) Die Anwendung erzeugt eine Bestellung im Inhouse-Format;2) die Bestellung im Inhouse-Format wird in eine EDIFACT-Nachricht ORDERS konvertiert;3) die EDIFACT
35、-Nachricht ORDERS wird in eine XML-ORDERS bersetzt und bermittelt.ANMERKUNG Die Umsetzung in XML kann auch direkt aus dem Inhouse-Format erfolgen.b) Auf der Seite des Lieferanten:1) Der Lieferant als Empfnger der XML-ORDERS visualisiert das Dokument unter Verwendung einergeeigneten Browser-Software
36、und einem Style Sheet (z. B. XSL, das passende XSL Style Sheet wirdbei Bedarf mitgeliefert). Darber hinaus besteht die Mglichkeit der Integration der XML-ORDERS indie Anwendung zur Erreichung automatisierter Ablufe;2) der Lieferant benutzt ein z. B. vom Kunden bereitgestelltes Template zum Ausfllen
37、einer XML-INVOIC in einer geeigneten Browser-Software und bermittelt diese an seinen Kunden.ANMERKUNG Optional kann zur Erreichung automatisierter Ablufe die XML-INVOIC aus der Anwendung erzeugtwerden.c) Auf der Seite des Kunden:1) Die XML-INVOIC wird vom Kunden als Empfnger in eine EDIFACT-Nachrich
38、t INVOIC bersetzt;2) die EDIFACT-Nachricht INVOIC wird in eine Rechnung im Inhouse-Format konvertiert;3) die Rechnung im Inhouse-Format wird von Anwendung bearbeitet.ANMERKUNG 1 Die Umsetzung in das Inhouse-Format kann auch direkt aus XML erfolgen.Diese Norm basiert auf der W3C-Empfehlung XML 1.0 vo
39、n 1998 und der UN/EDIFACT-Syntax, Version 3,nach DIN EN 29735.ANMERKUNG 2 Die englische Version der XML 1.0 Recommendation steht im Web unterhttp:/www.w3.org/TR/1998/REC-xml-19980210 zur Verfgung. Die deutsche bersetzung ist unter http:/www.min- zu finden. Weitere Teile der XML-bersetzung sind (jetz
40、t oder inZukunft) unter http:/ zu finden.Seite 13DIN 16557-4:2002-04Werdegang einer Bestellung beim Kunden bis zur bertragung im XML-Format an den nicht EDIFACT-fhigenLieferanten. Dieser generiert aus seiner Anwendung eine entsprechende Rechnung im XML-Format, die an denKunden zurckgesendet wird. Di
41、e Rckumsetzung ins EDIFACT- bzw. Inhouse-Format verluft in umgekehrterReihenfolge der Bestellung.Bild B.1 Beispiel fr den Einsatzbereich dieser NormSeite 14DIN 16557-4:2002-04LiteraturhinweiseDIN EN 28879:1991, Informationsverarbeitung; Textverarbeitung und -kommunikation; Genormte Verallge-meinerte
42、 Auszeichnungssprache (SGML) (ISO 8879:1986 + A1:1988); EN 28879:1990.DIN EN 29735:1994, Elektronischer Datenaustausch fr Verwaltung, Wirtschaft und Transport(EDIFACT) Syntax-Regeln auf Anwendungsebene (ISO 9735:1988, gendert und neu gedruckt 1990);(nderung 1:1992); (enthlt nderung A1:1993); Deutsch
43、e Fassung EN 29735:1992 + A1:1993.Normen der Reihe ISO 8859, Information technology 8-bit single-byte coded graphic character sets.ISO 10179:1996, Information technology Processing languages; Document Style Semantics and Specifi-cation Language (DSSSL).ISO/IEC 10646-1:1993, Information technology Universal multiple-octet coded character set (UCS) Part 1: Architecture and basic multilingual plane.XML 1.0:1998, eXtensible Markup Language.
