DIN 16557-5-2002 Electronic data interchange for administration commerce and transport (EDIFACT) - Part 5 Rules for generation of XML scheme files (XSD) on the basis of EDI(FACT) i.pdf

1、1DEUTSCHE NORM November 2002Elektronischer Datenaustausch fr Verwaltung, Wirtschaftund Transport (EDIFACT)Teil 5: Regeln zur Generierung von XML-Schema-Dateien (XSD) ausEDI(FACT)-Anwendungsbeschreibungen (ISO/TS 20625:2002)16557-5ICS 35.240.60Electronic data interchange for administration, commerce

2、and transport(EDIFACT) Part 5: Rules for generation of XML scheme files (XSD) onthe basis of EDI(FACT) implementation guidelines (ISO/TS 20625:2002)change de donnes informatis pour ladministration, le commerce, et letransport (EDIFACT) Partie 5: Rgles pour la gnration de fichiers deschma XML (XSD) b

3、ass sur les guides de mise en oeuvre dEDI(FACT)(ISO/TS 20625:2002)Die Internationale Technische Spezifikation ISO/TS 20625:2002 Electronic datainterchange for administration, commerce and transport (EDIFACT) Part 5: Rules forgeneration of XML scheme files (XSD) on the basis of EDI(FACT) implementati

4、onguidelines“ ist unverndert in diese Deutsche Norm bernommen worden.Nationales VorwortDiese Norm wurde vom Normenausschuss Browesen (NB), Arbeitsausschuss 3 EDI/EDIFACT“ (NB-AA 3)erarbeitet. Der NB ist u. a. fr normative Festlegungen im Anwendungsbereich des elektronischenDatenaustausches im weiter

5、en Sinn auch Electronic Commerce zustndig.DIN 16557 Elektronischer Datenaustausch fr Verwaltung, Wirtschaft und Transport (EDIFACT) bestehtaus: Teil 2: Wrterbuch (zz. Entwurf) Teil 3: Allgemeine Einfhrung fr Einheitliche Nachrichtentypen (UNSMs) Teil 4: Regeln fr die Auszeichnung von UN/EDIFACT-bert

6、ragungsdateien mit der ExtensibleMarkup Language (XML) unter Einsatz von Document Type Definitions (DTDs) Teil 5: Regeln zur Generierung von XML-Schema-Dateien (XSD) aus EDI(FACT)-AnwendungsbeschreibungenFortsetzung Seite 2 bis 57Normenausschuss Browesen (NB) im DIN Deutsches Institut fr Normung e.V

7、. DIN Deutsches Institut fr Normung e.V. .Jede Art der Vervielfltigung, auch auszugsweise, Ref. Nr. DIN 16557-5:2002-11nur mit Genehmigung des DIN Deutsches Institut fr Normung e. V., Berlin, gestattet. Preisgr. 19 Vertr.-Nr. 0019Alleinverkauf der Normen durch Beuth Verlag GmbH, 10772 BerlinDIN 1655

8、7-5:2002-112Deutsche bersetzungElektronischer Datenaustausch fr Verwaltung, Wirtschaft und Transport(EDIFACT)Regeln zur Generierung von XML-Schema-Dateien (XSD) ausEDI(FACT)-AnwendungsbeschreibungenEinleitungTraditionelle EDI-Normen stellen eine Syntax bereit fr die Implementierung von Dateninhalten

9、 aus unter-schiedlichen Geschftsprozessen durch die Verwendung von Datenelementen, Segmenten und Nachrichten-typen. XML stellt zunchst lediglich die Syntax zur Verfgung. Die derzeitig stattfindene Neuerfindung vonEDI in der XML-Welt fhrt zu ausufernden neuen Aufwnden, die das von EDI bisher ungelste

10、 Zielkonterkarieren: die Anbindung von kleinen und mittelstndischen Unternehmen (KMU) an elektronischeGeschftsprozesse.Diese Norm soll aufzeigen, wie bestehendes EDI-Know-how mit der XML-Syntax verbunden werden kann,um EDI-Daten fr XML-Anwender schnell und konsistent mit vorhandenen Anwendungen nutz

11、bar zu machen.EDIFACT Message Implementation Guidelines (MIGs) beschreiben die Umsetzung der Norm in einenkonkreten Geschftsprozess. Deshalb sind MIGs die geeignete Quelle zur Ableitung von XML-Schemata.Diese Norm soll den Prozess der Umsetzung normieren.1 AnwendungsbereichDiese Norm legt Regeln zur

12、 Ableitung von Vorgaben fr XML-Schemata aus EDI-MIGs fest. Damit wird einkonsistentes Verfahren zur Darstellung von semantischen Sachverhalten gegeben.Primr wird von MIGs fr UN/EDIFACT ausgegangen. Diese Norm gilt grundstzlich aber auch fr andereEDI-Standards.Diese Norm gilt nicht fr DTDs.2 Normativ

13、e VerweisungenDiese Norm enthlt durch datierte oder undatierte Verweisungen Festlegungen aus anderen Publikationen.Diese normativen Verweisungen sind an den jeweiligen Stellen im Text zitiert, und die Publikationen sindnachstehend aufgefhrt. Bei datierten Verweisungen gehren sptere nderungen oder be

14、rarbeitungendieser Publikationen nur zu dieser Norm, falls sie durch nderung oder berarbeitung eingearbeitet sind.Bei undatierten Verweisungen gilt die letzte Ausgabe der in Bezug genommenen Publikation (einschlielichnderungen).ISO 8601:2000-12, Data elements and interchange formats Information inte

15、rchange Representationof dates and times.ISO 9735-1:1998-10, Electronic data interchange for administration, commerce and transport (EDIFACT) Application level syntax rules (Syntax version number: 4, Syntax release number: 1) Part 1: Syntax rulescommon to all parts.DIN 16557-5:2002-1133 Begriffe, Sy

16、mbole und AbkrzungenFr die Anwendung dieser Norm gelten die folgenden Begriffe, Symbole und Abkrzungen:3.1BSR (en: Basic Semantics Register)Verzeichnis semantischer Grundbegriffe3.2BSU (en: Basic Semantic Unit)semantischer Grundbegriff3.3DTD (en: Document Type Definition)Standard-Strukturbeschreibun

17、g eines SGML- und XML-Dokumentes3.4EDI (en: Electronic Data Interchange)elektronischer Datenaustausch3.5EDIFACT (en: Electronic Data Interchange for Administration, Commerce and Transport)elektronischer Datenaustausch fr Verwaltung, Wirtschaft und Transport3.6ELEMENTsyntaktischer Baustein, der Daten

18、 enthlt und/oder Attribute besitzt3.7HTML (en: Hyper Text Markup Language)Layout-orientierte Seitenbeschreibungssprache3.8MIG (en: Message Implementation Guideline)Nachrichten-Anwendungsbeschreibung N1)3.9NAMEEin Name in XML beginnend mit einem Buchstaben oder einem erlaubten Interpunktionszeichen,

19、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 reserviert3.10SGML (en: Standard Generalised Mar

20、k-up Language) N2)3.11TagFormatierungsanweisung oder semantische AuszeichnungNationale Funote 1: Message Implementation Guideline steht hier stellvertretend fr Subsets, Conventions, Profiles,Anwendungsdokumentationen und hnliche Begriffe zur Bezeichnung von Spezifikationen eines EDI-Standards frbest

21、immte Anwendungsflle.Nationale Funote 2: Hochsprache zur Ableitung von Auszeichnungssprachen wie HTML und XMLDIN 16557-5:2002-1143.12TemplateSchablone bzw. vorgegebenes Referenzmuster, das mit der gesamten zu erkennenden Entitt oder einemihrer Teile verglichen wird3.13XLL (en: Extensible Link Langua

22、ge)Verknpfungssprache zu XML3.14XML (en: Extensible Markup Language)Auszeichnungssprache u. a. zur Strukturierung von Daten3.15XSD (en: Extensible Scheme Definition)XML-Schema3.16XSL (en: Extensible Stylesheet Language)Visualisierungssprache zu XML3.17W3C (en: World Wide Web Consortium)International

23、es Konsortium zur Entwicklung technischer Spezifikationen fr das WWW4 Typische Inhalte von Message Implementation Guidelines4.1 Ebene: MIGa) Identifikation des MIG;b) Identifikation des zugrunde liegenden EDIFACT-Verzeichnisses;c) Identifikation des Nachrichtentyps und gegebenenfalls des Branchen-Su

24、bsets;d) sonstiger Text.4.2 Ebene: Nachrichtentypa) Struktur des Nachrichtentyps (Segmente und Segmentgruppen) sowie die davon benutztenTeilmengen;b) Status (Standard versus Anwendung) der benutzten Segmente und Segmentgruppen;c) positionsspezifische Namen und Beschreibungen der Segmente und Segment

25、gruppen;d) Beispiele;e) Abhngigkeiten zwischen Segmenten und Segmentgruppen;f) sonstiger Text, Kommentare auf Nachrichtentyp-Ebene.4.3 Ebene: Segmente und Datenelementgruppena) Struktur der Segmente und Datenelementgruppen sowie der benutzten Teilmengen daraus;b) Status (Standard versus Anwendung) d

26、er Datenelemente und Datenelementgruppen;c) Abhngigkeiten zwischen Datenelementen und Datenelementgruppen innerhalb eines Segmentes undinnerhalb des Nachrichtentyps;DIN 16557-5:2002-115d) positionsspezifische Namen und Beschreibungen;e) Beispiele;f) sonstiger Text, Kommentare.4.4 Ebene: Datenelement

27、a) Eigenschaften der EDI-Datenelemente (Typ, Lnge) und deren MIG- und positionsbezogeneAnwendungseinschrnkungen;b) positionsspezifische Namen und Beschreibungen der Datenelemente, gegebenenfalls zustzlicheindeutige Tags und Beschreibungen, z. B. aus Datenrepositories wie dem ISO-BSR (sieheISO/TS 166

28、68;c) Beispiele;d) sonstiger Text, Kommentare;e) zugelassene Werte;f) Konstanten;g) explizit aufgefhrte Codes aus EDIFACT- oder (ISO-/UN-)Verweis-Codelisten;h) explizit aufgefhrte anwenderdefinierte Codes;i) implizit aufgefhrte Codes aus EDIFACT- oder (ISO-/UN-)Verweis-Codelisten;j) implizit aufgefh

29、rte anwenderdefinierte oder andere Codes, die auf externe, nicht im Regelwerkaufgefhrte Codelisten verweisen;k) Regeln, denen die Werte eines Datenelementes gengen mssen;l) Zuordnung zu Feldern von Anwendungen bzw. Flatfiles.5 Anforderungen an Ableitungsregeln fr Schemataa) Die unter Abschnitt 4 auf

30、gelisteten fachlichen Informationen des MIG mssen so vollstndig wie ntigin Schemata bernommen werden.b) Die Struktur des zugrunde liegenden MIG muss nachvollziehbar sein (XML und traditioneller EDI-Guide mssen strukturkompatibel sein.).c) Die resultierenden XML-Nachrichten sollten mglichst schlank s

31、ein.d) Von den verschiedenen Varianten, mit denen semantische Sachverhalte in XML dargestellt werdenknnen, sollte die Norm im Idealfall eine als die verbindliche festlegen.e) Der Entwickler des MIG entscheidet, welche Daten fachlich wichtig und welche Strukturen fr seineAnwendung sinnvoll sind. Er b

32、estimmt damit, welche Strukturelemente in das Schema bernommenwerden.DIN 16557-5:2002-1166 Regeln zur Erzeugung von XML-Schemata aus EDI-MIGsANMERKUNG Das Krzel din in den Beispielen dieses Abschnittes dient lediglich zu demonstrativen Zwecken undkann entweder ausgelassen oder durch andere passende

33、Krzel ersetzt werden.6.1 Regel 1: Tag-Benennung6.1.1 Variante 1Die Namen der XML-Zielstruktur werden aus den EDI-Tags gebildet, die je nach Strukturebene (Segment-gruppe, Segment, Datenelementgruppe oder Datenelement) einen festgelegten Prfix erhalten:M_“+ Nachrichtentyp + Suffix Beispiel: M_ORDERSG

34、_“+ Segmentgruppe + Suffix Beispiel: G_SG36 oder G_LIN_ALCS_“+ Segment + Suffix Beispiel: S_LINC_“+ Datenelementgruppe + Suffix Beispiel: C_C082_2D_“+ Datenelement + Suffix Beispiel: D_3035 oder D_3035_10Der Suffix ist optional und entsteht bei unterschiedlicher semantischer Verwendung von EDI-Eleme

35、nten.Wird die XML-Schema-Datei aus einem EDIFACT-MIG erstellt, ist nur der Prefix D_“ notwendig. Dieanderen Prefixe sind in Hinblick auf andere EDI-Standards, bei denen Datenelementgruppen undDatenelemente numerische Tags haben, zu verwenden.Die zweite Notation fr Segmentgruppen-Tags kann dort angew

36、endet werden, wo der zugrunde liegendeEDI-Standard keine expliziten Segmentgruppen ausweist oder aus anderen Grnden die Notation derjeweiligen Trigger-Segmente bevorzugt wird. In diesen Fall ist die Schachtelung der Segmentgruppen alsSequenz ihrer Trigger-Segmente anzugeben.Der W3C-XML-Standard verl

37、angt selbsterklrende Tags“. EDI(FACT)-Tags erfllen diese Bedingung eherals natrlichsprachliche Tags, weil sie eine eingefhrte Lingua Franka fr EDI-Spezialisten darstellen.Beispiel:6.1.2 Variante 2Aus geeigneten Kommentaren werden, wenn gewnscht, sprechende“ Tags generiert. Diese Methodewird alternat

38、iv zugelassen. Wird mit “sprechenden“ Tags gearbeitet, so wird die EDI-Herkunft desentsprechenden Elementes entweder ber ein Attribut-Wert (siehe auch 6.9) oder mit anderenDokumentationsmitteln eindeutig dokumentiert.DIN 16557-5:2002-117Beispiel:.6.2 Regel 2: Struktur6.2.1 Gleichartige Namen fhren z

39、u aggregierten Elementen (siehe 6.10).6.2.2 Wenn eine Unterscheidung zwischen verschiedenen semantischen Verwendungen des gleichenDatencontainers gewnscht ist, mssen auch verschiedene Tags oder Namen zugewiesen werden,entweder durch Ergnzung eines Suffixes zum EDI-Tag oder durch Verwendung unterschi

40、edlicher Namen.6.2.3 Das XML-Schema kann zustzlich klammernde Elemente fr Gruppen gleichartiger Nachrichtenund die bertragungsdatei selbst enthalten (analog UNG-UNE und UNB-UNZ in UN/EDIFACT).6.2.4 Jede im MIG dokumentierte Verwendung eines EDI-Datencontainers (Nachrichtentyp, Segment-gruppe, Segmen

41、t usw.) kann als eigenstndiges XML-Element abgebildet werden. Die vorhandene EDI-Struktur ist Quelle der XML-Zielstruktur, somit muss das XML-Schema strukturkompatibel zum EDI-MIGsein. Die Menge der erzeugten XML-Elemente ist kleiner oder gleich der Menge der EDI-Elemente.ANMERKUNG Die Art, wie der

42、Anwender den MIG geschrieben hat, muss den Bedrfnissen des Geschfts-prozesses gengt haben. Dementsprechend muss auch das Schema strukturiert sein. Sind zum Beispiel im MIG“Dokumentendatum“ und “Gefordertes Lieferdatum“ in zwei getrennten Instanzen des DTM-Segmentes beschrieben,so entstehen daraus au

43、ch zwei getrennte XML-Elemente. Sind “Dokumentendatum“ und “Gefordertes Lieferdatum“ ineinem DTM-Segment beschrieben, so entsteht auch nur ein XML-Element.DIN 16557-5:2002-118Beispiele fr 6.2.1 und 6.2.2:Variante 1:Der Beispiel-Guide enthlt zwei DTM-Segmente (siehe Bild 1).DTM (#1), Status M, Occurr

44、ence 1, Qualifier in DE 2005: 4, Name: Order_dateDTM (#2), Status M, Occurrence 1, Qualifier in DE 2005: 2, Name: Delivery_dateBild 1 Nachrichtenaufbau-Diagramm des Beispiel-Guides mit zwei DTM-SegmentenDie berfhrung in ein XML-Schema nach 6.2.1 fhrt zu:Type of dateDate/Time/PeriodANMERKUNG Das Elem

45、ent D_2005 ist ein “enumeration type“ und enthlt die zwei mglichen Werte 2 und 4.Alternativ wrde die Anwendung der Regel 6.2.2 resultieren in:Order dateDelivery dateDIN 16557-5:2002-119oderVariante 2:Eine implizite Dokumentation im Guide mit nur einen DTM-Segment (siehe Bild 2)DTM, Status M, Occurre

46、nce 2, Qualifier in DE 2005: 2 und 4Bild 2 Nachrichtenaufbau-Diagramm des Beispiel-Guides mit einem DTM-SegmentDie berfhrung in ein XML-Schema analog zum Beispiel in 6.2.1 fhrt zu:Type of dateOrder dateBeispiel fr 6.2.3:DIN 16557-5:2002-11106.3 Regel 3: Struktur-OptimierungWenn es erwnscht ist, dass

47、 die XML-Strukturen mglichst flach sind, knnen die folgenden Regelnangewendet werden. Fr die Integration in bestehende EDI-Systeme sollten jedoch die aus den System-erfordernissen abgeleiteten Mindestanforderungen fr die Datenstruktur erhalten bleiben.6.3.1 Zusammenfassende EDI-Objekte mssen nur ins

48、oweit nach XML berfhrt werden, als sie einezusammenfassende Funktion erfllen. Wenn das Segment nur ein Datenelement mit Geschftsdatenenhlt, gibt es keine zusammenfassende Funktion auf Segmentebene. Bei der Transformation in ein XSD-Schema kann diese Segmentebene daher weggelassen werden.6.3.2 Im MIG

49、 nicht benutzte Elemente des Primr-Standards sind wegzulassen.6.3.3 Konstante Qualifier oder konstante Codes sind nicht in die XML-Struktur zu bertragen (fr einbestimmtes Datenelement wurde nur ein Code dokumentiert). Die entsprechenden Datenelemente knnenin XML wegfallen.Beispiel:Aus:Order datewird in Anwendung dieser Regel:Order dateDie Ebenen Segment und Datenelementgruppe werden nich