ImageVerifierCode 换一换
格式:PDF , 页数:14 ,大小:145.57KB ,
资源ID:653660      下载积分:10000 积分
快捷下载
登录下载
邮箱/手机:
温馨提示:
如需开发票,请勿充值!快捷下载时,用户名和密码都是您填写的邮箱或者手机号,方便查询和重复下载(系统自动生成)。
如填写123,账号就是123,密码也是123。
特别说明:
请自助下载,系统不会自动发送文件的哦; 如果您已付费,想二次下载,请登录后访问:我的下载记录
支付方式: 支付宝扫码支付 微信扫码支付   
注意:如需开发票,请勿充值!
验证码:   换一换

加入VIP,免费下载
 

温馨提示:由于个人手机设置不同,如果发现不能下载,请复制以下地址【http://www.mydoc123.com/d-653660.html】到电脑端继续下载(重复下载不扣费)。

已注册用户请登录:
账号:
密码:
验证码:   换一换
  忘记密码?
三方登录: 微信登录  

下载须知

1: 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。
2: 试题试卷类文档,如果标题没有明确说明有答案则都视为没有答案,请知晓。
3: 文件的所有权益归上传用户所有。
4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
5. 本站仅提供交流平台,并不能对任何下载内容负责。
6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

版权提示 | 免责声明

本文(DIN 16557-4-2002 de 3514 Electronic data interchange for administration commerce and transport (EDIFACT) - Part 4 Rules for the markup of UN EDIFACT interchanges with the eXtensibl.pdf)为本站会员(eveningprove235)主动上传,麦多课文库仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。 若此文所含内容侵犯了您的版权或隐私,请立即通知麦多课文库(发送邮件至master@mydoc123.com或直接QQ联系客服),我们立即给予删除!

DIN 16557-4-2002 de 3514 Electronic data interchange for administration commerce and transport (EDIFACT) - Part 4 Rules for the markup of UN EDIFACT interchanges with the eXtensibl.pdf

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.

copyright@ 2008-2019 麦多课文库(www.mydoc123.com)网站版权所有
备案/许可证编号:苏ICP备17064731号-1