SOA Guidelines. XML Schema Design. Matthias Furrer Principal Consultant. SOA Guidelines XML Schema Design

Transkript

1 SOA Guidelines XML Schema Design Matthias Furrer Principal Consultant Version 1.0 Seite 1/46

2 Dokument Information Status * Projektname Autor Initiale Bearbeitende Prüfende Abgeschlossen SOA Guidelines Matthias Furrer mfu Matthias Furrer Michel Hautle, Guido Schmutz, Markus Zehnder Genehmigende Verteiler * In Arbeit, In Prüfung, Abgeschlossen Änderungskontrolle, Prüfung, Genehmigung Version Datum Beschreibung, Bemerkung Name oder Rolle Draft Version Matthias Furrer Finale Version Matthias Furrer Version 1.0 Seite 2/46

3 Inhaltsverzeichnis 1 Einführung XML Version Generelle Konventionen die in diesem Dokument verwendet werden Formatierungsarten für zusammengesetzte Wörter bzw. Sätze Ziele Anforderungen Leitsätze Generelle XML Design Regeln Aufbau von XML Dokumenten XML Schema XML Dokumentinstanz Schemaweit gültige Standards Sprache von Typen, Elementen und Attributen XML Deklarationen Schema Attribute Kommentare und Dokumentation Verwendung von Namensräumen (Namespaces) Schema Namespace Element Namespace Attribut Namespace Logische und physische Strukturierung von XML Dokumenten Logische Strukturierung No Namespace Single Namespace Multiple Namespace Versionierung von XML Dokumenten Einschränkungen für den Schema-Entwurf Typen- und Struktur Definitionen im Schema Element-Definitionen im Schema Attributs-Definitionen im Schema Attribute für die Verwendung in Dokumentinstanzen Lokale Typendefinition Schema ohne Namensräume Empty Elements Erweiterte Regeln zum Design 26 Version 1.0 Seite 3/46

4 5.1 Lokale vs. Globale Deklaration Design Patterns Design Richtlinien Elemente vs. Typen Referenzierung von Komponenten aus anderen Namensräumen Attribute vs. Elemente Namenskonventionen Namens-Segmente in der Namensgebung von Elementen, Typen und Attributen Suffixe zur Bezeichnung des Datentyps Terminologie der Benennung von Businessobjekten Links XML-Spezifikationen Referenzen Anhang A Schema Beispiel 44 Version 1.0 Seite 4/46

5 Abbildungsverzeichnis Abbildung 1: Die XML Deklaration Abbildung 2: Deklaration der Schema-Attribute Abbildung 3: Definition der Strukturen und Elemente Abbildung 4: XML Dokumentinstanz Abbildung 5: Lokale Deklaration Russian Doll Abbildung 6: Globale Deklaration Salami Slice Abbildung 7: Globale Deklaration mit Typen Venetian Blind Abbildung 8: Globale Deklaration der Elemente und Typen Garden of Eden Version 1.0 Seite 5/46

6 1 Einführung Extensible Markup Language (XML) ist eine Sprache zur Beschreibung des Inhaltes eines Dokumentformates und dient zur strukturierten Darstellung von Daten in einem maschinell bearbeitbaren Format. XML ist definiert vom in den XML 1.0 Spezifikationen vom World Wide Web Consortium (W3C Die XML Spezifikationen definiert ein XML als wohlgeformt (oder englisch well-formed ) wenn es die definierten Syntax-Regeln einhält. Wird XML zum Datenaustausch verwendet, empfiehlt es sich darüber hinaus Regeln zu definieren, welche die formale Grammatik eines Dokumentes beschreibt und damit die syntaktische Struktur von XML Dokumentinstanzen definiert. Dies geschieht heute am meisten verbreitet mit Hilfe von XML Schema weitere gebräuchliche in diesem Dokument jedoch nicht behandelte - Schemasprachen sind Schematron oder RELAX NG. Der Standard definiert ein XML-Dokument als gültig (oder englisch valid), wenn es wohlgeformt ist, den Verweis auf eine Grammatik enthält und das durch die Grammatik beschriebene Format einhält. 1.1 XML Version 1.1 Die Zweite Version von XML 1.1. wurde 2004 veröffentlicht und enthält einige spezifische Erweiterungen: Unterstützung von Version 4.0 von Unicode Zusätzliche Zeichen in Namen sind erlaubt Zusätzliche Zeilenende-Zeichen (für EBCDIC Plattformen sind erlaubt) XML 1.1 ist nicht sehr weit verbreitet und wird nur zur Benutzung empfohlen wenn die spezifischen Erweiterungen benötigt werden. Erschwerend kommt dazu, dass die Spezifikationen für XML 1.1 noch nicht definitiv verabschiedet sind ( - Stand Juli 2011 Candiate Recommendation ) und noch nicht alle XML-Verarbeitungsprogramme Version 1.1 korrekt verarbeiten. Daher wird hier generell empfohlen die Version 1.0 einzusetzen. Version 1.0 Seite 6/46

7 1.2 Generelle Konventionen die in diesem Dokument verwendet werden Sämtliche Richtlinien werden in diesem Dokument zusätzlich in tabellarischer Form beschrieben, wie nachfolgend dargestellt. <Identifikations-Code> <Beschreibung der Regel> < Regel-Gruppe> Identifikations-Code Jede Regel, die in dem Dokument beschrieben wird, wird durch einen, innerhalb des Dokumentes eindeutigen Identifikationscode gekennzeichnet. Der Identifikationscode besteht aus einem dreistelligen Präfix und einer vierstelligen Regelnummer im folgenden Format: <präfix>- <regel-nummer> Folgende Präfixe werden zurzeit verwendet : Präfix GEN NMR BEP Beschreibung Generelle Entwurfsrichtlinie Namenskonvention (File, Tag, Namespace, usw.) Best Practice Version 1.0 Seite 7/46

8 Die Regelnummern werden übergreifend vergeben (ausser IBP) und sind nicht geordnet. Die nächste freie Regelnummer ist: 092. Beschreibung der Regel Eine möglichst kurze und prägnante Beschreibung der Regel, mit der Verwendung der unterschiedlichen Regeltypen im Text Regel Gruppe Die Regeln werden nach den Konventionen, die vom Request for Comment 2119 [REQ_COMM_2119] definiert wurden, in verschiedene, nachfolgend aufgelisteten Gruppen aufgeteilt. NOT NOT MAY Bedeutet eine absolute Anforderung, die zwingend eingehalten werden muss. Bedeutet ein absolutes Verbot, d.h. es darf auf keinen Fall verwendet werden. Bedeutet, dass es gute Gründe geben kann, die entsprechende Regel zu ignorieren. Die Auswirkungen müssen klar sein und gewichtet werden, bevor ein alternativer Weg beschritten wird. Bedeutet, dass es gute Gründe geben kann, dass das von der Regel beschrieben Verhalten akzeptabel oder sogar hilfreich ist. Die Auswirkungen müssen klar sein und gewichtet werden, bevor das entsprechende Verhalten implementiert wird. Bedeutet, dass der durch die Regel beschriebene Begriff wirklich optional ist. Es ist Sache des Anwenders, ob er die Regel anwendet oder nicht. Version 1.0 Seite 8/46

9 1.2.1 Formatierungsarten für zusammengesetzte Wörter bzw. Sätze Folgende Formatierungsarten werden in diesem Dokument verwendet: o o o UpperCamelCase (UCC) Upper Camel Case ist eine Art der Repräsentation von zusammengesetzten Wörtern oder Sätzen, bei der die einzelnen Wörter ohne Zwischenraum zusammengefügt werden, wobei jeweils der erste Buchstabe eines Wortes in Grossbuchstaben geschrieben werden: CreditCardExpirationDate LowerCamelCase (LCC) Lower Camel Case ist eine Art der Repräsentation von zusammengesetzten Wörtern oder Sätzen, bei der die einzelnen Wörter ohne Zwischenraum zusammengefügt werden, wobei ausser beim ersten Wort jeweils der erste Buchstaben eines Wortes in Grossbuchstaben geschrieben werden: creditcardexpirationdate LowerDashed (LD) Lower Dashed ist eine Art der Repräsentation von zusammengesetzten Wörtern oder Sätzen, bei der die einzelnen Wörter mit einem Bindestrich-Buchstaben getrennt zusammengefügt werden, wobei alles in Kleinbuchstaben geschrieben wird: credit-card-expiration-date Version 1.0 Seite 9/46

10 2 Ziele 2.1 Anforderungen Dieses Dokument bezieht sich insbesondere auf den Einsatz von XML und XML Schema im Zusammenhang mit dem Einsatz in Webservices und Service Orientierten Architekturen. Daher wird auf die Nutzung gewisser im XML-Standard vorhandener Funktionalitäten zur Ableitbarkeit und Erweiterbarkeit von Typendefinitionen bewusst verzichtet diese umfassen bspw. die Strukturelemente in XML Schema wie: xsd:any, xsd:extension, xsd:redefine. Obwohl diese zusätzliche Flexibilität in manchen Fällen nützlich sein kann, widersprechen sich diese teilweise mit der Idee von einem verbindlichen und möglichst transparenten kanonischen Schema, welches bei umfangreicheren Integrationslösungen dringend empfohlen wird. Darüber hinaus unterstützen weiterhin nicht alle XML Sprachen wie XSLT, XQUERY die komplette typbasierende Verarbeitung. 2.2 Leitsätze Die in diesem Dokument beschriebenen Leitsätze lehnen sich an den Design-Rules Standard von United Nations Centre for Trade Facilitation and Electronic Business [UN/CEFACT] an, welche u. a. verantwortlich für den internationalen Datenstandard EDIFACT und einer der Initiatoren von ebxml ist. Insbesondere sind die folgenden Design Principles als Basis für die in diesem Dokument aufgeführten Richtlinien berücksichtigt: XML Schema Erzeugung Die Design Richtlinien unterstützen sowohl die manuelle als auch die automatisierte Erzeugung von Schema Definitionen. Austausch und Nutzung in Anwendungen Die XML Schema und daraus erzeugte XML Dokumentinstanzen sind für eine Vielfalt von Datenaustausch- und Integrationsprozessen verwendbar. Tool Verwendung und Support Das Design von XML Schema ist nicht abhängig von verwendeten Werkzeugen für die Erstellung, Verwaltung oder Verarbeitung von XML Artefakten. Lesbarkeit XML Dokumentinstanzen sind intuitiv lesbar und möglichst klar im Kontext des Verwendungszwecks. Schema Features Das Design von XML Schema sollte die am häufigsten unterstützten Features der W3C XML Schema Definition Language Empfehlung verwenden. Technische Spezifikationen Namenskonventionen und Design Richtlinien basieren auf technischen Spezifikationen mit dem entsprechenden W3C Empfehlungsstatus. XML Schema Spezifikationen Namenskonventionen und Design Richtlinien sind vollkommen konform mit der W3C XML Schema Definition Language Empfehlung. Interoperability Die Anzahl von Möglichkeiten die gleiche Information in einem XML Schema oder Dokumentinstanz darzustellen soll möglichst niedrig gehalten werden. Version 1.0 Seite 10/46

11 Maintenance Das Design von XML Schema unterstützt und erleichtert die Wartbarkeit. Bezug auf andere Namensräume - Abhängigkeit zu anderen Namensräumen werden mit Vorsicht verwendet. Version 1.0 Seite 11/46

12 3 Generelle XML Design Regeln GEN-0001 Das XML Schema MUSS der Standardstruktur folgen, wie sie in Anhang A diese Dokumentes definiert ist. 3.1 Aufbau von XML Dokumenten Im Folgenden ist exemplarisch der Aufbau von XML Schema Dokumenten sowie XML Dokumentinstanzen gemäss den Spezifikationen vom World Wide Web Consortium beschrieben. Dies soll zum besseren Verständnis dienen, da die nachfolgenden Kapitel jeweils auf die einzelnen hier beschriebenen Namen und Definitionen referenzieren XML Schema XML Schema, häufig als XSD abgekürzt, bezeichnet ein XML Vokabular, welches es ermöglicht andere XML Dokumente so zu beschreiben, dass mittels standardisierter Programme getestet werden kann, ob ein gegebenes Dokument den im zugeordneten Vokabular definierten Regeln entspricht. XML Schema bestehen aus einer XML-Deklaration, der Definition der Schema-Attribute sowie einer nachfolgenden Beschreibung der in referenzierenden XML Dokumentinstanzen zugelassenen Strukturen, Typen und Attributen XML Deklaration: Die XML Deklaration besteht normalerweise aus der Definition der verwendeten XML- Version, Angaben zur Zeichencodierung sowie allenfalls weiterer Deklarationen. <?xml version= 1.0 encoding= UTF-8?> Abbildung 1: Die XML Deklaration Deklaration der Schema-Attribute: In den Schema Attributen werden die zu verwendenden Namensräume deklariert sowie weitere Attribute festgelegt, die als Voreinstellung für die im Schema deklarierten Datentypen und Elemente angewendet werden sollen. <xsd:schema targetnamespace= xmlns:tns= xmlns:xsd= xmlns:soabp-ct= elementformdefault= qualified attributeformdefault= unqualified version= 1.0 > </xsd:schema> Abbildung 2: Deklaration der Schema-Attribute Version 1.0 Seite 12/46

13 Definition der Strukturen und Elemente: Die Schemakomponenten sind im xsd:schema Containerelement eingeschlossen und beschreiben im Wesentlichen die gültigen Strukturen, Typen und Attribute für eine referenzierende Dokumentinstanz. Ebenfalls im Gültigkeitsbereich des Schemas befinden sich Instanzierungen zur Nachverwendung vorhandener Typen-Definitionen sowie Einbindungen von Deklarationen anderer Schemas und/oder Namensräumen. <xsd:schema > <xsd:import namespace= schemalocation= UnqualifiedDataType-v1.0.xsd /> <xsd:element name= CreditCard type= tns:creditcardtype /> <xsd:complextype name= CreditCardType > <xsd:sequence> <xsd:element name= CardNumber type= xsd:string minoccurs= 1 /> <xsd:element name= CardholderFirstName type= xsd:string minoccurs= 1 /> <xsd:element name= CardholderLastName type= xsd:string minoccurs= 1 /> <xsd:element name= ExpirationMonth type= soabp-ct:monthtype minoccurs= 1 /> <xsd:element name= ExpirationYear type= soabp-ct:monthtype minoccurs= 1 /> </xsd:sequence> </xsd:complextype> </xsd:schema> Abbildung 3: Definition der Strukturen und Elemente XML Dokumentinstanz Ein XML Dokumentinstanz besteht im Wesentlichen wiederum aus einer XML-Deklaration und beinhaltend nachfolgend die eigentlichen Nutzdaten, welche im Falle einer gewünschten Abhängigkeit von einem XML Vokabular auf das verwendete Schema und den dazugehörigen Namensraum referenzieren. <?xml version= 1.0 encoding= UTF-8?> <CreditCard xmlns:xsi= xsi:schemalocation= xmlns= > <CardNumber> </CardNumber> <CardholderFirstName>Hans</CardholderFirstName> <CardholderLastName>Muster</CardholderLastName> <ExpirationMonth>09</ExpirationMonth> <ExpirationYear>14</ExpirationYear> </CreditCard> Abbildung 4: XML Dokumentinstanz Version 1.0 Seite 13/46

14 3.2 Schemaweit gültige Standards Sprache von Typen, Elementen und Attributen Grundsätzlich ist XML in der Namensgebung von Typen, Elementen und Attributen offen. Aus Gründen der Wiederverwendbarkeit und zum breiteren Verständnis sollten die Elementund Attributnamen in englischer Sprache vergeben werden. Namensgebung in jeweiliger Landessprache sollten nur auf expliziten Wunsch verwendet werden. GEN-002 Alle Typen, Elements- und Attributsnamen SOLLTEN in englischer Sprache im XML Schema definiert werden XML Deklarationen GEN-003 Die XML Deklarationen für Dokumentinstanzen MUSS zwingend vorhanden sein. Beispiel: <?xml version= 1.0 encoding= UTF-8?> XML Version GEN-004 Jedes XML Schema MUSS die XML Version 1.0 verwenden Character Set GEN-005 Jedes XML Schema MUSS für die Zeichencodierung mindestens UTF-8 verwenden. GEN-006 Falls zwingende Gründe vorhanden sind KANN UTF-16 verwendet werden. MAY Schema Attribute Allgemein GEN-007 GEN-008 GEN-009 Der xsd Präfix MUSS zwingend definiert werden und auf den folgenden Namespace verweisen: Jedes XML Schema Dokument MUSS einen Target-Namespace über das xsd:targetnamespace Attribut definieren. Jede xsd:schemalocation Attribut-Deklaration innerhalb eines XML-Schemafiles MUSS eine URL enthalten, die über einen relativen Pfad aufgelöst werden kann. Version 1.0 Seite 14/46

15 Voreinstellungen BEP-010 BEP-011 BEP-012 BEP-013 Das xsd:elementformdefault Attribut MUSS deklariert sein und der Wert immer auf qualified gesetzt werden. Das xsd:attributeformdefault MUSS deklariert sein und der Wert immer auf unqualified gesetzt werden. Das xsd:finaldefault Attribut SOLLTE auf #all gesetzt werden als Voreinstellung des final Attributes für Elemente und komplexe Typen, um die Erweiterung oder Einschränkung von Typen im Schema selber zu verhindern Beispiel: finaldefault= #all Das xsd:blockdefault Attribut SOLLTE auf #all gesetzt werden als Voreinstellung des block Attributes für Elemente und komplexe Typen, von Typen um die Erweiterung oder Einschränkung in instanzierten Dokumenten durch Erweiterung, Ersetzung oder Einschränkung zu verhindern Beispiel: blockdefault= #all Schema-Version BEP-014 Das xsd:schema Versionsattribut MUSS immer deklariert werden. Beispiel: version= Kommentare und Dokumentation GEN-015 Jedes XML Schemafile MUSS einen Kommentar enthalten, welche dem folgenden Format entspricht : <!-- ===================================================--> <!-- ===== Element Declarations ===== --> <!-- ===================================================--> Im Anhang A befindet sich ein komplettes Beispiel der zu verwendeten Kommentare. Version 1.0 Seite 15/46

16 GEN-016 Jedes XML Schemafile SOLLTE einen Kommentar enthalten, welche dem folgenden Format entspricht. <xsd:annotation> <xsd:documentation lang= EN > This Schema will be used to process Credit Cards </xsd:documentation> </xsd:annotation> Optional kann das source= Attribut verwendet werden, beispielsweise mit einer Referenz auf die Ablage einer Dokumentation. source= > BEP-017 Bei der Verwendung des documentation Elementes SOLLTE die Sprache immer über das lang Attribut Qualifiziert werden. 3.3 Verwendung von Namensräumen (Namespaces) Namensräume in XML werden dazu verwendet um Elemente, Typen und Attribute in XML Dokumenten eindeutig adressieren zu können. Das heisst, Namespaces schaffen die Grundlage um das Vokabular eines XML-Dokumentes eindeutig zu identifizieren - und um in einem einzelnen Dokument mehrere dieser Vokabulare zu mischen oder zu vereinigen. Version 1.0 Seite 16/46

17 3.3.1 Schema Namespace BEP-018 Schema ohne Namensräume DUERFEN NICHT verwendet werden. NOT BEP-019 BEP-020 Die Möglichkeit des Default-Namespace DARF NICHT verwendet werden. Sowohl der XML Schema wie auch der Target-Namespace müssen explizit qualifiziert werden. Beispiel: <xsd:schema targetnamespace= xmlns:tns= </xsd:schema> Als einzige Ausnahme zur Regel BEP-019 KANN zur Vereinfachung der Default- Namespace auf den Namespace der XML Schema Definition gesetzt werden.. Beispiel: <xsd:schema targetnamespace= xmlns= </xsd:schema> MAY NMR-021 Der Target-Namespace im Schema MUSS immer die Major-Versionsnummer beinhalten Beispiel: targetnamespace= NMR-022 Die folgenden Namespace-Präfixe MUESSEN bei der Deklaration der W3C Namensräume verwendet werden: xsd= xsi= xsl= NMR-023 Für die Deklaration des Targetnamespace MUSS immer das Prefix tns verwendet werden Element Namespace BEP-024 Alle Elemente MUESSEN über einen Namespace qualifiziert sein. Dies wird per Default über das Schema Attribut elementformdefault= qualified eingestellt. Version 1.0 Seite 17/46

18 3.3.3 Attribut Namespace BEP-025 Global definierte Attribute (Attribute die auf der obersten Ebene im Schema deklariert worden sind und damit wiederverwendbar sind) MUESSEN über einen Namespace qualifiziert sein. BEP-026 Nicht global definierte Attribute DUERFEN NICHT über einen Namespace qualifiziert sein. Dies wird per Default über das Schema Attribut attributeform- Default= unqualified eingestellt. Aufgrund dieser Voreinstellung führt folgende Definition in der importierten Schema Definition: <xsd:element name= AttributeTestElement type= AttributeTestType /> <xsd:attribute name= globalattribute /> <xsd:complextype name= AttributeTestType > <xsd:sequence> <xsd:element name= String1 type= xsd:string /> <xsd:element name= String2 type= xsd:string /> </xsd:sequence> <xsd:attribute name = localattribute type= xsd:string /> </xsd:complextype> MAY NOT zu diesem XML Instanzdokument: <p:attributequalifying p:globalattribute= v1 xmlns:p= xmlns:p1= > <p1:attributetestelement localattribute= local > <p1:string1>string1</p1:string1> <p1:string2>string2</p1:string2> </p1:attributetestelement> </p:attributequalifying> Version 1.0 Seite 18/46

19 3.4 Logische und physische Strukturierung von XML Dokumenten Die XML Spezifikationen erlauben es, die Definition eines Schemas in mehreren physischen Dateien zu verwalten und diese zu einem logischen Dokument im gleichen oder unterschiedlichen Namensräumen zusammenzuführen. Nicht nur, aber insbesondere bei der Umsetzung eines kanonischen Schema (Canonical Schema) in einer SOA können diese Konzepte zur Modularisierung besonders hilfreich eingesetzt werden, um ein wiederverwendbares und gemeinsam nutzbares Vokabular von Entitäts- und Datendefinitionen zur Verfügung zu stellen Logische Strukturierung Grundsätzlich wird empfohlen, Kern-Entitäten für die oberste Hierarchie-Ebene zu definieren. Diese können beispielsweise sein: Customer, Order, Invoice. Für die nächste Ebene können dann wiederverwendbare Elemente wie Address, AccountInfo, PaymentInfo definiert werden - welche wiederum Definitionen von allgemeineren Elementen beziehen können welche dann in den Kern-Entitäten referenziert werden. BEP-027 Ein Schemafile SOLLTE für jede Kernentität erzeugt werden. BEP-028 BEP-029 Ein XML-Schemafile für eine Kernentität DARF NICHT wiederverwendbare Konstrukte definieren, die über ein separates XML Schemafile mittels einem xsd:include oder xsd:import referenziert werden können. Dies bedeutet, in diesem speziellen Fall darf nur genau ein globales Element definiert werden und das Schema muss nach dem Russian Doll Design Pattern implementiert werden. Referenzierung von Elementen aus anderen Namespace sind jedoch erlaubt. <xsd:element name= CreditCardEntity > <xsd:complextype> <xsd:sequence> <xsd:element name= id type= xsd:long /> <xsd:element name= descriptiontext minoccurs= 0 > <xsd:simpletype> <xsd:restriction base= xsd:string > <xsd:maxlength value= 50 /> </xsd:restriction> </xsd:simpletype> <xsd:element ref= cre:creditcard /> </xsd:sequence> </xsd:complextype> Deklaration von Listenelementen (Collections) MUESSEN immer im gleichen Schemafile erfolgen, wie die Haupt-Elemente (bspw. Entitäten) welche diese beinhalten. NOT Version 1.0 Seite 19/46

20 Dabei sollte berücksichtigt werden, dass eine feinere Granularität in der Aufteilung zwar die Wiederverwendbarkeit erhöht, auf der anderen Seite dadurch jedoch auch die gegenseitigen Abhängigkeiten steigen und damit Änderungen an einem Objekt unter Umständen grössere Auswirkungen auf mehrere Anwendungen haben. BEP-030 Die Abhängigkeiten und Referenzierungen der Schema untereinander SOLLTEN möglichst gering gehalten werden. Ein Schemafile sollte idealerweise nicht Abhängigkeiten über mehr als 3 oder 4 Hierarchiestufen haben. Beispiel: Customer referenziert auf Address ; Address referenziert auf Common. Im Schema für Common werden jedoch keine weiteren Elemente von weiteren Schemas mehr eingebunden. NOT Common Schema Zur vereinfachten Wiederverwendung wird für allgemein verwendete Datentypen ein eigenes Schema entweder pro Anwendungsdomäne oder übergreifend erstellt. BEP-031 Ein eigenes Schemafile MUSS definiert werden, für die Definition von Typen, welche Kandiaten zur häufigen Wiederverwendung als einzelne Elemente sind. Dabei muss je ein Schema für Qualifizierte und Unqualifizierte Typen erstellt werden. Qualifizierte Typen Types mit Restriktionen wie bspw. Address, SocialSecurityNumber Unqualifizierte Typen Types ohne Restriktionen, die jedoch voraussichtlich zu einem späteren Zeitpunkt erweitert werden. Bei grösseren Projekten, sollte dabei ein eigenes Common Schema pro Anwendungsdomäne z.b. Accounting, Orders, Master Data - erstellt werden Enumerations Um die Auswirkungen auf referenzierende Schema oder Anwendungen bei allfälligen Änderungen an erlaubten, bzw. eingeschränkten Feldinhalten zu minimieren, werden Typen mit Enumerations in einem eigenen Schema definiert. BEP-032 Ein eigenes Code-List XML Schemafile SOLLTE definiert werden, für die Definition von Typen, die Enumerations beinhalten. Jeder Typ muss dabei in einem eigenen Schema definiert sein Speicherort der XML Schema Das Deployment von XML Schema sollte immer in einen physischen Pfad erfolgen, welcher den logischen Aufbau sowie die Anwendungsdomäne repräsentiert. Diese Struktur sollte auch aus dem verwendeten Namensraum ersichtlich sein und sollte so aufgebaut werden, dass sie möglichst einfach über einen relativen Pfad aufgelöst werden kann. Version 1.0 Seite 20/46

21 BEP-033 Der physische Speicherort der Schemadefinition SOLLTE dem folgenden Pattern gehorchen: URI scheme://<hostname>/[:<port>]/<domain>/<schema type> scheme Bezeichnung des Zugriffsprotokolls: http file port Angabe der Portnummer falls nicht Default des verwendeten Protokolls hostname Qualifizierter Hostname unter dem der angegebene Pfad erreichbar ist. domain ein Bezeichner der Geschäftseinheit oder definierten SOA Domäne zu der die Schemadefinition logisch zugeordnet wird. schema type ein Token, welcher den Typ des XML Schema Dokumentes indentifiziert: schema codelist common wsdl Beispiele: No Namespace Schema-Definitionen müssen immer über einen Namespace qualifiziert sein. BEP-034 Jedes Schema MUSS zwingend einen Targetnamespace deklarieren. Siehe auch GE-018. Das Weglassen von Namespaces um diese dann auf der obersten Referenzierungsebene bspw. Schemadefinition der Kern-Entität oder WSDL unter einem globalen Namespace wie zusammenzuführen ist nicht erlaubt Single Namespace Das xsd:include Element wird verwendet wenn ein grosses Schema in mehrere kleine - und möglicherweise wiederverwendbare - Teile aufgebrochen werden soll. Dabei müssen alle Deklarationen der eingelesenen Dateien den gleichen Targetnamespace wie das einlesende Dokument verwenden. BEP-035 Ein Objekt das mittels xsd:include in den gleichen Namensraum eingebunden wird, DARF NICHT in noch weiteren Objekten verwendet werden. Single Namespace sollte nur in Ausnahmefällen verwendet werden, um grössere Schema zur besseren Übersicht in mehrere physische Dateien aufzuteilen. Definitionen von Typen die mehrfach bspw. in verschiedenen Entitäten - verwendet werden, müssen immer in einem eigenen Namensraum deklariert werden. NOT Version 1.0 Seite 21/46

22 3.4.4 Multiple Namespace Das xsd:import Element erlaubt die Referenz auf Schemas, die in einem anderen Namensraum deklariert sind. Damit werden in einem einlesenden Dokument die Deklarationen anderer Schemas eingelesen, sodass deren Inhalte referenziert werden können. BEP-036 Mehrfach verwendete Objekte, die von mehreren Namensräumen referenziert werden wie z.b. Address - MUESSEN immer in einem eigenen Namensraum deklariert und mit xsd:import eingebunden werden. Die Definition von Elementen und Typen die mehrfach verwendet werden, müssen immer in eigenem Namensraum deklariert werden. 3.5 Versionierung von XML Dokumenten Der Versionsname von XML Dokumenten setzt sich immer aus einer Major-Release Nummer und einer Minor-Release Nummer zusammen. major Major-Versionsnummer minor Minor Versionsnummer Dabei gilt zwingend immer der Grundsatz: Neue Releases innerhalb einer Minor-Versionsnummer sind immer abwärtskompatibel das heisst diese dürfen keine Modifikationen enthalten, welche die Validierung innerhalb der gleichen Major-Versionsnummer beeinträchtigen. Konkret heiss dies, dass XML Dokumentinstanzen, welche aufgrund eines früheren Schemas des gleichen Major-Release erstellt wurden nach wie vor gültig sein müssen. BEP-037 Der Wert der XML-Schema Major-Versionsnummer MUSS ein Wert > 0 sein. BEP-038 BEP-039 BEP-040 BEP-041 Eine Minor-Versionsänderung MUSS sich darauf beschränken, neuen optionalen XML Inhalt zu definieren, bestehenden XML Inhalt zu erweitern oder optionale Refinements. Eine Minor-Versionsänderung DARF NICHT einen existierenden XML Schema Artefakt umbenennen. Änderungen in Minor-Versionen DUERFEN NICHT die semantische Kompatibilität mit Vorgängerversion verletzten, die die gleiche Major-Version aufweisen. Ein XML Schema MUSS seine eigene Version anpassen, wenn ein referenziertes, externes XML Schema auf eine neue Version geändert wird. NOT NOT Version 1.0 Seite 22/46

23 4 Einschränkungen für den Schema-Entwurf Um eine maximale Interoperabilität von XML Dokumenten zu gewährleisten, sind zusätzlich zur generellen Struktur eines XML Schema einige zusätzliche Einschränkungen notwendig,. 4.1 Typen- und Struktur Definitionen im Schema Gemischter Inhalt BEP-042 Mixed Content DARF NICHT verwendet werden. Dies ist nicht zugelassen: <wrapper> <element>value</element> other content </wrapper> NOT BEP-043 Das Attribut xsd:mixed DARF NICHT verwendet werden. NOT Überschreiben von Definitionen im Schema BEP-044 Das xsd:redefine Element DARF NICHT verwendet werden. NOT BEP-045 Das xsd:extension Element DARF NICHT verwendet werden. NOT Externe Programm oder Verarbeitungs-Instruktionen BEP-046 Das xsd:notation Element DARF NICHT verwendet werden. NOT Kompositoren in Modellgruppen BEP-047 Der Kompositor <all> in Model Groups SOLLTE NICHT verwendet werden. NOT 4.2 Element-Definitionen im Schema Empty Elements Um Laufzeitfehler bei Transformationen und Zuordnungen zu vermeiden, bzw. zusätzliche Errorhandling Blöcke zu minimieren, werden leere Elemente nicht zugelassen. BEP-048 Empty Elements DUERFEN NICHT verwendet werden. NOT BEP-049 Das xsd:nillable Attribut DARF NICHT verwendet werden. NOT Version 1.0 Seite 23/46

24 Deklaration Vorkommnisse von Elementen BEP-050 BEP-051 Elemente SOLLTEN mit Occurance-Indikatoren deklariert werden. Beispiel: <element name= firstname minoccurs= 1 maxoccurs= 1 /> Elemente vom DatenTyp xsd:string mit einer optionalen Verwendung im Schema (minoccurs= 0 ) SOLLTEN immer mit einer Längenrestriktion deklariert werden Nicht typisierte Elemente BEP-052 BEP-053 BEP-054 Das xsd:any Element SOLLTE NICHT verwendet werden. In Schemadeklaration welche gegen aussen publiziert werden (nicht ausschliesslich von der eigenen Anwendung verwendet), dürfen diese nicht verwendet werden. Der DatenTyp xsd:anysimpletype für Elementsdefinitionen Elementdefinitionen DARF NICHT verwendet werden. Bei Elementsdeklarationen mit Referenzierung auf einen Typ MUSS das type= Attribut immer angegeben und definiert werden. NOT NOT Default Werte Im Sinne der Nachvollziehbarkeit von Tests sollten durch Validierungsfunktionen keine Werte im XML Instanzdokument ersetzt werden. BEP-055 Das xsd:default Attribut für Elementdefinitionen SOLLTE NICHT verwendet werden NOT Ersetzungsgruppen BEP-056 Das xsd:substitutiongroup Attribut für Elementdefinitionen DARF NICHT verwendet werden NOT Datentypen BEP-057 Der xsd:id/xsd:idref/xsd:idrefs Datentyp DARF NICHT verwendet werden. NOT 4.3 Attributs-Definitionen im Schema Nicht typisierte Attribute BEP-058 Das xsd:anyattribute Attribut DARF NICHT verwendet werden. NOT Default Werte Im Sinne der Nachvollziehbarkeit von Tests sollten durch Validierungsfunktionen keine Werte im XML Instanzdokument ersetzt werden. Version 1.0 Seite 24/46

25 BEP-059 Das xsd:default Attribut für Attributsdefinitionen SOLLTE NICHT verwendet werden NOT 4.4 Attribute für die Verwendung in Dokumentinstanzen Lokale Typendefinition BEP-060 Lokale Typendefinitionen im XML-Dokument DUERFEN NICHT verwendet werden. NOT BEP-061 Das xsi:type Attribut DARF NICHT verwendet werden. NOT Schema ohne Namensräume BEP-062 Das xsi:nonamespaceschemalocation Attribut DARF NICHT verwendet werden. NOT Empty Elements BEP-063 Das xsi:nil= true Attribut SOLLTE NICHT verwendet werden. NOT Version 1.0 Seite 25/46

26 5 Erweiterte Regeln zum Design 5.1 Lokale vs. Globale Deklaration Die Sprachelemente von XML Schema erlauben sowohl die Deklaration von globalen als auch lokalen Elementen und Typen. Eine Komponente eines XML Schemas wird als global bezeichnet, wenn diese als unmittelbares Child von <schema> definiert ist, wohingegen lokale Komponenten verschachtelt in einer anderen Komponente deklariert sind (z.b. innerhalb eines Elementes als <complextype>) Design Patterns Lokale Deklaration - Russian Doll Design Bei diesem Pattern wird nur ein globales Element definiert, alle anderen Elemente sind lokal definiert, das Schema bündelt alle Elemente zu einer gültigen Deklaration <xsd:element name= CreditCard > <xsd:complextype> <xsd:sequence> <xsd:element name= CardNumber type= xsd:string minoccurs= 1 /> <xsd:element name= CardholderFirstName type= xsd:string minoccurs= 1 /> </xsd:sequence> </xsd:complextype> Abbildung 5: Lokale Deklaration Russian Doll Charakteristik Beinhaltet nur ein globales Element, alle anderen Elemente sind lokal definiert Wiederverwendbarkeit nur für das Root Element gegeben Erlaubt die Steuerung der Namespacesichtbarkeit auf globaler Ebene durch entsprechende Definition von elementformdefault Namespaces können gegen aussen verborgen werden Schema muss in einem File definiert werden Version 1.0 Seite 26/46

27 Globale Deklaration - Salami Slice Design In diesem Design Pattern werden alle Elemente als globales Element definiert. Da es keine verschachtelten Element-Deklarationen gibt, können alle Elemente über das gesamte Schema wiederverwendet werden. <xsd:element name= cardnumber type= xsd:string /> <xsd:element name= cardholderfirstname type= xsd:string /> <xsd:element name= CreditCardType > <xsd:complextype> <xsd:sequence> <xsd:element ref= cardnumber minoccurs= 1 /> <xsd:element ref= cardholderfirstname minoccurs= 1 /> </xsd:sequence> </xsd:complextype> Abbildung 6: Globale Deklaration Salami Slice Charakteristik Alle Elemente werden global deklariert Erlaubt die Wiederverwendbarkeit von Elemente auch in anderen Dokumenten Kein hidden Namespace gegen aussen möglich Namespace ist in Dokumentinstanzen immer sichtbar. Version 1.0 Seite 27/46

28 Globale Deklaration durch Typen - Venetian Blind Design Wie beim Salami Slice Design werden in diesem Pattern Definitionen global deklariert, im Unterschied dazu existiert aber nur ein globales Element. Für die globalen Deklarationen werden hier Typen anstelle von Elementen verwendet. <xsd:simpletype name= CardNumberType > <xsd:restriction base= xsd:string > </xsd:restriction> </xsd:simpletype> <xsd:simpletype name= CardholderFirstNameType > <xsd:restriction base= xsd:string > <xsd:minlength value= 1 /> </xsd:restriction> </xsd:simpletype> <xsd:element name= CreditCard > <xsd:complextype> <xsd:sequence> <xsd:element name= CardNumber type= CardNumberType minoccurs= 1 /> <xsd:element name= CardholderFirstName type= CardholderFirstNameType minoccurs= 1 /> </xsd:sequence> </xsd:complextype> Abbildung 7: Globale Deklaration mit Typen Venetian Blind Charakteristik Beinhaltet nur ein globales Element Individuelle Komponenten werden als Typen definiert Erlaubt die Wiederverwendbarkeit aller Typen und des globalen Root Elements Erlaubt die Aufteilung der Definitionen in mehrere Files Sichtbarkeit des Namespace kann auf Schemaebene über elementformdefault Switch gesteuert werden Limitierte Kapselung durch Exponierung der Typen Version 1.0 Seite 28/46

29 Globale Deklaration der Elemente und Typen - Garden of Eden Hierbei handelt es sich um eine Kombination des Venetian Blind und des Salami Slice Patterns. Alle Elemente und Typen werden global definiert. <xsd:element name= CardNumber type= CardNumberType /> <xsd:element name= CardholderFirstName type= CardholderFirstNameType /> <xsd:element name= CreditCard type= CreditCardType /> <xsd:simpletype name= CardNumberType > <xsd:restriction base= xsd:string /> </xsd:simpletype> <xsd:simpletype name= CardholderFirstNameType > <xsd:restriction base= xsd:string > <xsd:minlength value= 1 /> </xsd:restriction> </xsd:simpletype> <xsd:complextype name= CreditCardType > <xsd:sequence> <xsd:element ref= CardNumber minoccurs= 1 /> <xsd:element ref= CardholderFirstName minoccurs= 1 /> </xsd:sequence> </xsd:complextype> Abbildung 8: Globale Deklaration der Elemente und Typen Garden of Eden Charakteristik Alle Elemente und Typen werden global deklariert Erlaubt die Wiederverwendbarkeit von Typen und Elementen Erlaubt die Aufteilung der Definitionen in mehrere Files Limitierte Kapselung durch Exponierung der Typen Version 1.0 Seite 29/46

30 5.1.2 Design Richtlinien In der Literatur finden sich teilweise unterschiedliche Interpretationen der oben beschriebenen Patterns. In einigen Quellen wird das Venetian Blind Pattern beschrieben mit der Restriktion so wie oben wiedergegeben - nur ein einziges globales Element zu deklarieren. In anderen Beschreibungen existiert diese Restriktion nicht und es wird dabei empohlen, zusätzlich die voraussichtlich wiederzuverwendenden Komponenten selektiv als Elemente zu definieren. In anderen Quellen wird dieses Design Modell auch als Hybrid bezeichnet. Um eine möglichst hohe Wiederverwendbarkeit gewährleisten zu können und da gemäss vorliegenden Richtlinien zwingend die Qualifizierung von Elementen vorgegeben ist, sollten im Design von XML Schema das Hybrid Design Modell implementiert werden. BEP-064 BEP-065 BEP-066 BEP-067 BEP-068 Das XML Schema Design SOLLTE dem Hybrid-Ansatz zwischen Venetian Blind und Garden of Eden Pattern folgen. Typen werden global deklariert, Elemente welche voraussichtlich wiederverwendet werden, sind dabei ebenfalls im globalen Namensraum definiert. Es müssen dabei jedoch nicht zwingend alle Elemente global deklariert werden. Komplexe Typen SOLLTEN immer benannt werden und nie inline (innerhalb eines Elementes) definiert werden. Globale Elemente und Attribute SOLLTEN immer die type= Form verwenden und keine anonymen Typen enthalten. Elemente innerhalb von Model Groups (choice oder sequence) SOLLTEN immer die ref= Form und nie die type= Form verwenden. Die Definition von einfachen Typen (xsd:simpletype) KANN anonyme einfache Typendefinitionen beinhalten. Die Definition des einfachen Typen selber jedoch, SOLLTE NICHT anonym in einem Attribut oder Element erfolgen. MAY / NOT Version 1.0 Seite 30/46

31 5.2 Elemente vs. Typen Grundsätzlich können globale Komponenten sowohl als Types wie auch als Elemente im Schema definiert werden. Allgemein gilt als Best Practice im Zweifelsfall einen Typen zu definieren, da diese flexibler definiert werden können und Elemente nachträglich auf einfache Weise noch ergänzt werden können. Es ist weitgehend etabliert, Komponenten welche nicht vorgesehen sind als Elemente in XML Dokumentinstanzen zu erscheinen, ebenfalls als komplexe Type zu implementieren. Sowohl Oracle Service Bus (OSB) wie auch BPEL 2.0 unterstützen die Definition von Variablen basierend auf globalen Elementen und Typen, während hingegen BPEL 1.1 nur Variablen von globalen Elementen zulässt. GEN-069 Jedes XML Schema Dokument, welches direkt von einer WSDL Definition eingebunden wird, MUSS auf oberster Ebene die Deklaration eines Root Elements enthalten, auf welches in der Message-Definition des Services referenziert werden kann Referenzierung von Komponenten aus anderen Namensräumen Falls Komponenten aus anderen Namensräumen verwendet warden, soll dessen Namensraum immer auf der Elementebene ersichtlich bleiben. Dies wird erreicht indem solche importierten Objekte in der ref= und nicht der type= Form eingebunden werden. Version 1.0 Seite 31/46

32 BEP-070 Wenn Komponenten von anderen Namensräumen wiederverwendet werden, MUESSEN diese immer als Element und nicht als Typen - referenziert und im Herkunftsdokument entsprechend definiert werden. Andernfalls erhält das übergeordnete Element den Namespace des referenzierenden Schemas. Beispiel: <xsd:sequence> <xsd:element name= id type= xsd:long /> <xsd:element ref= cca:creditcard /> </xsd:sequence> BEP-071 Führt zu folgender Qualifizierung des Namensraums im XML Instanzdokument: <?xml version= 1.0 encoding= UTF-8?> <mas:creditcardentity xmlns:mas= xmlns:cre= xmlns:xsi= xsi:schemalocation= Master.xsd > <mas:id>789</mas:id> <cre:creditcard> <cre:cardnumber>1234</cre:cardnumber> <cre:cardholderfirstname>hans</cre:cardholderfirstname> </cre:creditcard> </mas:creditcardentity> Falls das gleiche Element eines anderen Namensraums innerhalb von Model Groups mehrfach verwendet wird, MUSS dieses innerhalb eines Types, welcher wiederum einen eindeutigen Namen hat, definiert werden. Beispiel: <xsd:element name= CreditCardInfo > <xsd:complextype> <xsd:sequence> <xsd:element name= id type= xsd:long /> <xsd:element name= MainCreditCard minoccurs= 1 > <xsd:complextype> <xsd:sequence> <xsd:element ref= cre:creditcard /> </xsd:sequence> </xsd:complextype> <xsd:element name= AltCreditCard minoccurs= 0 > <xsd:complextype> <xsd:sequence> <xsd:element ref= cre:creditcard /> </xsd:sequence> </xsd:complextype> <xsd:element name= OldCreditCards minoccurs= 0 maxoccurs= unbounded > <xsd:complextype> <xsd:sequence> <xsd:element cre= cre:creditcard /> </xsd:sequence> </xsd:complextype> </xsd:sequence> </xsd:complextype> Version 1.0 Seite 32/46

33 BEP-072 Wenn Komponenten des gleichen Namensraumes wiederverwendet werden, SOLLTEN diese immer mit der Type= Form referenziert werden. Version 1.0 Seite 33/46

34 5.3 Attribute vs. Elemente Aus Gründen der Klarheit und Abgrenzung sowie der leichteren Erweiterbarkeit wird hier empfohlen, Attribute generell nur für Metadaten zu verwenden. Als Metadaten gelten dabei Informationen über die im Dokument enthaltenen Daten oder das Dokument selber so wie beispielsweise die Versionsnummer des Schemas oder alternative Feldbeschreibungen. BEP-073 Für die Repräsentation von Daten MUESSEN Elemente verwendet werden - und nicht Attribute. BEP-074 Attribute SOLLTEN nur für Metadaten verwendet werden Version 1.0 Seite 34/46

35 6 Namenskonventionen NMR-075 Die Namen der Elemente, Attribute und Typen SOLLTEN aus Wörtern gebildet werden, die im definierten Wörterbuch zu finden sind. SOLLTE NMR-076 Für den Namen von Attributen MUSS LowerCamelCase (LCC) verwendet werden. NMR-077 NMR-078 NMR-079 Für den Namen der Elementen und Typen MUSS UpperCamelCase (UCC) verwendet werden. Dem Namen eines ComplexType und eines SimpleType MUSS der Suffix Type angehängt werden. Bespiel: AddressType Dem Namen von Elementen oder Typen, welche wiederum Iterationen mit dem Attribut maxoccurs> 1 von Elementen beinhalten, SOLLTE der Suffix Collection angehängt werden. Beispiel: <xsd:complextype name= PersonsCollection > <xsd:sequence> <xsd:element maxoccurs=unbounded ref=person /> <xsd:sequence> </xsd:complextype> Alternativ kann der Plural des im Listenelement definierten Element verwendet werden z.b. Persons. Allerdings sollt dies innerhalb einer Domäne konsistent gehandhabt werden. NMR-080 Sämtliche Namen SOLLTEN eine Maximallänge von 35 Zeichen nicht überschreiten. NMR-081 NMR-082 NMR-083 NMR-084 NMR-085 NMR-086 NMR-087 Element-, Attribut- und Typ-Namen MUESSEN innerhalb eines Namensraums eindeutig sein. Underscore (_), Punkte (.) und Bindestrich (-) Zeichen SOLLTEN NICHT verwendet werden oder SOLLTEN für spezielle Anforderungen reserviert sein. Elemente, Attribute und Typen MUESSEN in Singularform definiert werden, ausser das Konzept selbst existiert nur Pluralform (z.b. GoodsQuantity). Die Namen der XML Elemente, Attribute und Typen MUESSEN aus Kleinbuchstaben [az], Grossbuchstaben [A-Z], Zahlen [0-9] und Underscore-Zeichen [_] gebildet werden. Die Namen der XML Elemente, Attribute und Typen DUERFEN NICHT Akronyme, Abkürzungen und andere Wortkürzungen verwenden, ausser sie sind in der projektspezifisch zu erstellenden Liste der erlaubten Abkürzungen und Akronyme vorhanden. Akronyme und Abkürzungen, die aufgelistet werden, MUESSEN immer anstelle der ausgeschriebenen Wörter verwendet werden. Akronyme MUESSEN immer komplett in Grossbuchstaben vorkommen, ausser das Akronym steht am Anfang eines Attributnamen. In diesem Fall MUSS das Akronym in Kleinbuchstaben geschrieben sein. NOT Version 1.0 Seite 35/46

36 NMR-088 Ein XML Schema Namespace MUSS dem folgenden Pattern gehorchen: URN urn:<organization>:<organization hierarchy>[:<organization hierarchy level>]*:<schema type>[:<package>]+[:<status>]:v<major-version> URL hierarchy>[/<organization hierarchy level>]*/<schema type>[/<package>]+[/<status>]/v<major-version> wobei: organization ein Identifier der Organisation, welche die Schemadefinition zur Verfügung stellt organization hierarchy die erste Stufe einer Hierarchie innerhalb der Organisation, welche die Schemadefinition zur Verfügung stellt organization hierarchy level 0 oder mehrere Hierarchiestufen der Organisation, welche die Schemadefinition zur Verfügung stellt schema type ein Token, welcher den Typ des XML Schema Dokumentes indentifiziert: schema codelist documentation package - eine oder mehrere Stufen von Packages getrennt durch ein / Zeichen status der optionale Status des WSDL-Dokumentes: draft standard major die Major Versionsnummer Beispiele: ylist/v1 Version 1.0 Seite 36/46

37 NMR-089 Die Filenamen von XML Schemas MUESSEN dem folgenden Pattern gehorchen: <schema-module-name>_<major>.<minor>.xsd sämtliche Punkten, Leerzeichen und andere Trennzeichen müssen entfernt werden. wobei: Schema-module-name Name des Schemamoduls major Major-Versionsnummer minor Minor Versionsummer NMR-090 Das xsd:schema Versionsattribut MUSS dem folgenden Pattern gehorchen: <xsd:schema... version= <major>.<minor>[.<revision>] wobei: <major> - sequentielle Nummer mit der Major-Version <minor> - sequentielle Nummer mit der Minor-Version <revision> - optionale, sequentielle Nummer mit der Revision-Nummer 6.1 Namens-Segmente in der Namensgebung von Elementen, Typen und Attributen Die Namen von Elementen, Attributen und Typen in einer Schemadefinition sollten sich wo möglich und sinnvoll aus einem projektspezifisch zu erstellenden Vokabular von standardisierten Begriffen zusammenzusetzen. Falls vorhanden und möglich empfiehlt sich auch eine nahe Anlehnung von Komponentennamen an die Namensgebung des zugrundeliegenden Objekt- oder Datenmodells Suffixe zur Bezeichnung des Datentyps In der folgenden Tabelle sind im Sinne eines Beispiels und nicht abschliessend einige essentielle Begriffe aufgeführt, welche als Suffix in Komponentennamen verwendet werden sollten. Bezeichner Beschreibung Primitive Datentypen Amount Binary Ein numerischer Wert, der einen monetären Wert darstellt. Die Währungseinheit kann dabei explizit oder implizit definiert sein. Beispiele: UnitCostAmount, UnitPriceAmount, PartnerFeeAmount Eine Sequenz von binären Ziffern um beispielsweise Dokumente wie Word oder PDF einzubinden. Beispiele: DocumentationBinary, AttachmentBinary xsd:decimal xsd:double xsd:float xsd:integer xsd:base64binary xsd:hexbinary Version 1.0 Seite 37/46

38 Code Date DateTime Duration Identifier Indicator Measure Ein Character String (Buchstaben, Zahlen oder Symbole) kann verwendet werden, um einen kürzeren oder sprach-unabhängiges Token zu haben, der einen Wert oder Text repräsentiert oder ersetzt. Codes werden normalerweise in Codelisten für jeden Attributtyp verwaltet. Beispiele: CountryCode, CurrencyCode Ein Tag in einem bestimmten Kalenderjahr (ISO ) als Darstellung im gregorianischen Kalender. Beispiele: ExpirationDate, ShipmentDate Eine Kombination aus Datumsangeben des gregorianischen Kalenders und Zeitangaben Beispiele: CreationDateTime, ReceiptDateTime Eine Darstellung eines Zeitraumes in Jahren, Monaten, Wochen, Tagen, Stunden, Minuten, Sekunden und Sekundenbruchteilen im ISO 8601 Format. Beispiele: ActivityDuration, WorkTimeDuration Ein Charakter String (Buchstaben, Zahlen oder Symbole) als eindeutiger Bezeichner einer Instanz eines Objektes. Beispiele: CustomerIdentifier, OrderIdentifier Ein Bezeichner aus einer Liste von 2 sich gegenseitig ausschliessenden Werten, welche den einzigen möglichen Zustand einer bestimmten Eigenschaft wiedergeben. Beispiele: ActivationStatusIndicator, EligibilityIndicator Ein numerischer Wert um physische Dimensionen eines Objektes zu beschreiben. Wird typischerweise immer im Kontext einer Masseinheit verwendet. Beispiele: WeightMeasure, LengthMeasure xsd:normalizedstring xsd:string xsd:token xsd:date xsd:datetime xsd:duration xsd:normalizedstring xsd:string xsd:token xsd:boolean xsd:decimal xsd:double xsd:float xsd:integer Name Die Benennung als Unterscheidungsmerkmal xsd:normalizedstring Version 1.0 Seite 38/46

39 eines bestimmten Objektes wie Person, Sache, Ort oder Konzept. xsd:string xsd:token Ordinal Percent Quantity Rate Ratio Text Beispiele: FirstName, LocationName Eine Zahl die einen mathematischen Wert darstellt, welche für Aufzählungen, Reihenfolgen und Sortierungen verwendet wird. Beispiele: RankingOrdinal, OrderOrdinal Ein Wert der eine Fraktion von hundert als Quotient ausdrückt. Beispiele: DiscountPercent, TaxPercent Ein numerischer Wert mit welchem eine Einheit von nicht monetären Werten ausgedrückt wird. Üblicherweise wird dieser Wert immer im Kontext einer Masseinheit ausgedrückt. Beispiele: OrderQuantity, AvailableQuantity Eine Menge, Betrag, Häufigkeit oder Faktor, der gegen eine Basiseinheit gemessen und als Quotient ausgedückt wird. Beispiele: InterestRate, ConversionRate Eine Beziehung von zwei unabhängigen Mengen, welche die gleiche Masseinheit oder Währung verwenden. Ratio kann als Quotient oder Proportion ausgedrückt werden. Beispiele: CompletionRatio, NetIncomeRatio Eine Charakter Zeichenkette in der Form einer Sprache welche zur unstrukturierten Beschreibung eines Objektes verwendet wird. Beispiele: InvoiceText, RemarksText xsd:integer xsd:positiveinteger xsd:nonnegativeinteger xsd:unsignedint xsd:unsignedlong xsd:decimal xsd:double xsd:float xsd:integer xsd:decimal xsd:double xsd:float xsd:integer xsd:decimal xsd:double xsd:float xsd:integer xsd:decimal xsd:double xsd:float xsd:integer xsd:normalizedstring xsd:string xsd:token Time Die Angabe einer Tageszeit im ISO Format mit oder ohne Zeitzonenangabe, welche in Stunden, Minuten, Sekunden und Bruchteilen davon aufgelöst werden kann. xsd:time Beispiele: DeliveryTime, StartTime Value Ein numerischer Wert zur Darstellung von quantifi- xsd:decimal Version 1.0 Seite 39/46