Eigenschaften und Besonderheiten des Katalogdaten-Austauschformates BMEcat 2005


Fachbuch, 2017
157 Seiten

Leseprobe

Übersicht

1 Einleitung
1.1 Gegenstand des Buches und Motivation
1.2 Zielgruppe und vorausgesetzte Kenntnisse
1.3 Autor
1.4 Konventionen
1.5 Aufbau des Buches
1.6 Die Spezifikation
1.7 Validierung

2 Katalogaustauschformate und BMEcat
2.1 Fachlicher Kontext
2.2 Die Organisation hinter BMEcat
2.3 Lizenzen
2.4 Verbreitung
2.5 BMEcat-Versionen

3 BMEcat-2005-Dokumente
3.1 XML als technische Basis
3.2 Kompatibilität zur Vorgängerversion BMEcat-1.2
3.3 Grundlegende Konzepte
3.4 Struktur eines BMEcat-Dokuments
3.5 Bausteine eines BMEcat-Dokuments

4 Quellenangaben

5 Stichwortverzeichnis

Inhaltsverzeichnis

1 Einleitung
1.1 Gegenstand des Buches und Motivation
1.2 Zielgruppe und vorausgesetzte Kenntnisse
1.3 Autor
1.4 Konventionen
1.5 Aufbau des Buches
1.6 Die Spezifikation
1.7 Validierung
1.7.1 Begriffe
1.7.2 Die Anforderungen zur BMEcat-2005-Validierung
1.7.3 Die Rolle der XML-Schema-Datei
1.7.4 Die Auslegung der Spezifikation
1.7.4.1 Allgemeines
1.7.4.2 Textauslegung
1.7.5 Die Bedeutung der Zertifizierung

2 Katalogaustauschformate und BMEcat
2.1 Fachlicher Kontext
2.2 Die Organisation hinter BMEcat
2.3 Lizenzen
2.4 Verbreitung
2.5 BMEcat-Versionen

3 BMEcat-2005-Dokumente
3.1 XML als technische Basis
3.1.1 Einführung
3.1.2 XML-Deklaration
3.1.3 XML-Entitäten
3.1.4 Groß- und Kleinschreibung
3.1.5 Reihenfolge der XML-Elemente
3.1.6 Länge der XML-Element-Inhalte
3.2 Kompatibilität zur Vorgängerversion BMEcat-1.2
3.2.1 Einschränkungen
3.2.1.1 Einsprachiger Katalog
3.2.1.2 Element FEATURE_SYSTEM
3.2.1.3 Eingeschränkte Wertebereiche
3.2.2 Besonderheiten
3.2.2.1 Umbenennung von Elementnamen
3.2.2.2 Weiterverwendbarkeit alter Elemente
3.2.2.3 Gemischte Verwendung von alten und neuen Elementen
3.2.2.4 Gemischte Verwendung alter und neuer Mechanismen
3.2.2.5 Anreicherung von alten Elementen mit neuen Kindelementen
3.3 Grundlegende Konzepte
3.3.1 Muss- und Kann-Bestandteile
3.3.1.1 Die Begriffe Element, Attribut und Feld
3.3.1.2 Definition von Muss- und Kann-Feldern
3.3.1.3 Muss- und Kann-Sequenzen
3.3.2 Kardinalitäten
3.3.2.1 Notation
3.3.2.2 Die Kardinalität sprachabhängiger Elemente
3.3.2.3 Bestimmung von Element-Kardinalitäten
3.3.2.3.1 Element CONFIG_FORMULA
3.3.2.3.2 Unterelemente PHONE und FAX von CONTACT_DETAILS
3.3.2.3.3 Das Spannungsfeld zwischen Spezifikation und XML-Schema-Datei
3.3.2.4 Unterschiedliche Kardinalitäten gleicher Elemente
3.3.3 Aufruf gleichnamiger Unterelemente
3.3.4 Redundanzvermeidung
3.3.4.1 Vorgabewerte
3.3.4.1.1 Definition
3.3.4.1.2 Vorgabewerte bei Muss-Elementen
3.3.4.2 Vererbung von Vorgabewerten
3.3.4.2.1 Vererbung in Katalogdatenbereiche
3.3.4.2.2 Vererbung von Elementsammlungen
3.3.4.2.3 Vererbung bei Multimedia-Angaben
3.3.4.2.3.1 Einführung
3.3.4.2.3.2 Pfad-Präfix statt Vererbung
3.3.4.2.3.3 Weitere Aspekte zu Multimedia-Angaben
3.3.4.3 Geschäftspartner
3.3.4.3.1 Einführung
3.3.4.3.2 Bestandteile
3.3.4.3.3 Identifikatoren
3.3.4.3.4 Referenzierung
3.3.4.4 Gebiete
3.3.4.5 Formeln
3.3.5 Multi-Lieferanten-Katalog
3.3.6 Mehrsprachigkeit
3.3.6.1 Voreingestellte Sprache
3.3.6.2 Einsprachige Dokumente
3.3.6.3 Mehrsprachige Dokumente
3.3.6.4 Sprachabhängigkeit von Elementen
3.3.6.4.1 Element AGREEMENT_DESCR
3.3.6.4.2 Element COST_TYPE
3.3.6.4.3 Element FNAME
3.3.6.4.4 Element FVALUE
3.4 Struktur eines BMEcat-Dokuments
3.4.1 Überblick
3.4.2 Transaktionen
3.4.2.1 Die Transaktion T_NEW_CATALOG
3.4.2.2 Die Transaktion T_UPDATE_PRODUCTS
3.4.2.3 Die Transaktion T_UPDATE_PRICES
3.4.3 Kopfbereich
3.4.4 Produkte
3.4.4.1 Aufbau
3.4.4.2 Produktmerkmale
3.4.4.2.1 Allgemeines
3.4.4.2.2 Besonderheiten
3.4.4.2.2.1 Elemente PRODUCT_FEATURES und FEATURE
3.4.4.2.2.2 Element REFERENCE_FEATURE_SYSTEM_NAME
3.4.4.2.2.3 Element REFERENCE_FEATURE_SYSTEM_ID
3.4.4.2.2.4 Element CLASSIFICATION_SYSTEM_FEATURE_TEMPLATE
3.4.4.2.2.5 Element REFERENCE_FEATURE_GROUP_NAME
3.4.4.2.2.6 Element REFERENCE_FEATURE_GROUP_ID2
3.4.4.2.2.7 Element GROUP_PRODUCT_ORDER
3.4.4.2.2.8 Element FEATURE
3.4.4.2.2.9 Element FNAME
3.4.4.2.2.10 Element FT_IDREF
3.4.4.2.2.11 Element FREF
3.4.4.2.2.12 Element FVALUE_DETAILS
3.4.4.3 Preise
3.4.4.3.1 Allgemeines
3.4.4.3.2 Besonderheiten
3.4.4.3.2.1 Gültigkeit eines Preises
3.4.4.3.2.2 Element DATETIME
3.4.4.3.2.3 Element PRODUCT_PRICE
3.4.4.3.2.4 Element PRICE_AMOUNT
3.4.4.3.2.5 Steuerangaben zu Preisen
3.4.4.3.2.6 Element CALCULATION_SEQUENCE
3.4.4.4 Produktreferenzen
3.4.4.4.1 Verweisart
3.4.4.4.2 Die Elemente PROD_ID_TO und SUPPLIER_IDREF
3.4.4.4.3 Die Elemente CATALOG_ID und CATALOG_VERSION
3.4.5 Klassifikationssysteme
3.4.5.1 Allgemeines
3.4.5.2 Besonderheiten
3.4.5.2.1 Element CLASSIFICATION_SYSTEM
3.4.5.2.2 Anzahl und Bezeichnung von Hierarchiestufen
3.4.5.2.3 Merkmalsgruppen
3.4.5.2.4 Das Element FT_ID
3.4.5.2.5 Das Element FT_NAME
3.4.5.2.6 Das Element FT_IDREF
3.4.6 Kataloggruppensysteme
3.4.6.1 Allgemeines
3.4.6.2 Besonderheiten
3.4.7 Abbildung von Produkten auf ein Kataloggruppensystem
3.4.7.1 Allgemeines
3.4.7.2 Besonderheiten
3.4.8 Formeln
3.4.8.1 Allgemeines
3.4.8.2 Besonderheiten
3.4.9 Produktkonfiguration
3.4.9.1 Allgemeines
3.4.9.2 Besonderheiten
3.4.9.2.1 Dokumenten-Pfad zum Element CONFIG_INFO
3.4.9.2.2 Element CONFIG_FORMULA
3.4.10 Integrated Procurement Point
3.4.10.1 Allgemeines
3.4.10.2 Besonderheiten
3.4.10.2.1 Element LANGUAGE
3.4.10.2.2 Element IPP_SUPPLIER_PID
3.4.10.2.3 Element IPP_USER_INFO
3.4.10.2.4 Element PASSWORD
3.4.11 Benutzerdefinierte Erweiterungen
3.5 Bausteine eines BMEcat-Dokuments
3.5.1 Identifikatoren (IDs)
3.5.1.1 Eindeutigkeit
3.5.1.2 Globale Identifikatoren
3.5.1.3 Identifikatoren für Dokumenten-Bereiche
3.5.1.4 Kombinierte Identifikatoren
3.5.1.5 Sprachabhängige Identifikatoren
3.5.1.6 Implizite Identifikatoren
3.5.2 Referenzen
3.5.2.1 Allgemeines
3.5.2.2 Besonderheiten
3.5.2.2.1 Einstufige Referenzen
3.5.2.2.1.1 Element FUNIT
3.5.2.2.1.2 Element SUPPLIER_PIDREF
3.5.2.2.1.3 Element IPP_PARAM_NAMEREF
3.5.2.2.2 Zweistufige Referenzen
3.5.2.2.2.1 Elemente PARTY_IDREF und CONTACT_IDREF
3.5.2.2.2.2 Elemente AGREEMENT_IDREF und AGREEMENT_LINE_IDREF
3.5.2.2.3 Sprachabhängige Referenzen
3.5.2.2.4 Mehrfachreferenzen
3.5.2.2.5 Attributierte Referenzen
3.5.2.2.6 Code-übergreifende Referenzen
3.5.3 Datentypen
3.5.3.1 Basisdatentypen
3.5.3.1.1 Datentyp dtBOOLEAN
3.5.3.1.2 Datentyp dtDATETIME
3.5.3.1.3 Datentyp dtDATETYPE
3.5.3.1.4 Datentyp dtTIMEZONETYPE
3.5.3.2 Aufzählungsdatentypen
3.5.3.2.1 Länder
3.5.3.2.2 Sprachen
3.5.3.2.3 Währungen
3.5.3.2.4 Maßeinheiten und Bestelleinheiten
3.5.3.3 Spezielle Datentypen
3.5.4 Zulässige Wertebereiche
3.5.4.1 Direkte Festlegungen
3.5.4.1.1 Element CATALOG_VERSION
3.5.4.1.2 Element EAN
3.5.4.1.3 Element INCOTERM
3.5.4.1.4 Element LEADTIME
3.5.4.1.5 Element MIME_TYPE
3.5.4.1.6 Element TIMEZONE
3.5.4.2 Indirekte Festlegungen
3.5.4.2.1 Element FVALUE
3.5.4.2.2 Elemente TERM_CONDITION und TERM_EXPRESSION
3.5.5 Schreibweisen von Elementen

4 Quellenangaben

5 Stichwortverzeichnis

1 Einleitung

1.1 Gegenstand des Buches und Motivation

Auf den ersten Blick ist das Katalogaustauschformat BMEcat-2005 relativ einfach und verständlich aufgebaut. Bei näherer Betrachtung zeigen sich jedoch unerwartete Details und Überraschungen.

Diese Erfahrung wurde dem Autor des vorliegenden Buches zuteil, als er sich mit den Einzelheiten der Spezifikation von BMEcat-2005 befasste. Die Kenntnisse über BMEcat-2005 waren für den Autor die notwendige Voraussetzung zur Implementierung eines Software-Werkzeuges. Das Software-Werkzeug hat unter anderem zum Ziel, beliebige BMEcat-2005-Dokumente auf Korrektheit im Sinne der Spezifikation zu prüfen. Um das eigene Software-Werkzeug auf Praxistauglichkeit zu testen, wandte der Autor das Werkzeug auf einige öffentlich im Internet verfügbare BMEcat-2005-Dokumente an. Das Ergebnis verwunderte: Die BMEcat-2005-Dokumente ergaben bei der Prüfung Fehler.

Um diesem überraschenden Ergebnis nachzugehen, weitete der Autor die Tests aus. 15 unterschiedliche, öffentlich verfügbare BMEcat-2005-Dokumente unterschiedlichster Größe, von mindestens fünf unterschiedlichen Generator-Werkzeugen stammend, wurden mit dem Werkzeug einer Prüfung unterzogen. Darunter befanden sich auch Dokumente einiger größerer, namhafter Anwenderunternehmen. Doch auch hier war das Ergebnis vergleichbar: Kaum eines der BMEcat-2005-Dokumente war fehlerfrei; die Skala der Fehler reichte von marginalen Kleinigkeiten bis hin zu deutlichen Fehlern. Um sicherzugehen, unterzog der Autor die vom Werkzeug beanstandeten Konstrukte einem manuellen Abgleich mit der Spezifikation. Die Einwände blieben. Sicherlich könnte im Einzelfall eingewandt werden, dass die Spezifikation etwas anders zu interpretieren ist. Auch kann von der kleinen Stichprobe hinsichtlich der Anzahl der geprüften BMEcat-2005-Dokumente keine Allgemeingültigkeit beansprucht werden. Die Ergebnisse bilden jedoch allemal ein deutliches Indiz dafür, dass die Situation nicht so ist, wie sie sein sollte.

Vor dem Hintergrund der unbefriedigenden Testergebnisse entstand die Idee zu dem vorliegenden Buch. Das Buch ist nicht als Lehrbuch konzipiert. Ebenso wenig geht es um das Präsentieren vollständiger und praxisrelevanter Beispiele. Vielmehr geht es im vorliegenden Buch um das Aufzeigen einer Reihe von Besonderheiten und Feinheiten von BMEcat-2005. Zugrunde gelegt wird die Spezifikation von BMEcat-2005.

Es ist die Überzeugung des Autors, dass ein Standard, der nicht konsequent korrekt eingesetzt wird, viel Potential vergibt; Abweichungen vom Standard erfordern bilaterale Zusatzaufwände, die dem Zweck der Standardisierung zuwider laufen, und den Standard letztendlich entwerten. Mit dem Schreiben des Buches ist die Hoffnung verbunden, die derzeitige Situation zu verbessern.

1.2 Zielgruppe und vorausgesetzte Kenntnisse

Das Buch zielt auf Leser, die sich konkret mit dem BMEcat-2005-Standard beschäftigen. Die Leser sollten in der Lage sein, die Spezifikation von BMEcat-2005 zu verstehen und zu interpretieren. Dazu sind grundlegende Kenntnisse und Erfahrungen im E-Business hilfreich. Vorausgesetzt werden auch IT-Basiskenntnisse: Leser sollten das Datenformat XML[1] entweder bereits kennen oder sich parallel zum Buch einarbeiten.

1.3 Autor

Der Autor besitzt Universitäts-Diplomgrade in den Fächern Informatik und Wirtschaftswissenschaften. Beruflich kann er auf mehrjährige Erfahrungen in den Bereichen Warenwirtschaft, Beschaffung und E-Commerce zurückgreifen. Insbesondere entwickelt und vertreibt der Autor ein Software-Werkzeug, das unter anderem zur Validierung, Inhaltsabfrage und Weiterverarbeitung von BMEcat-2005-Dokumenten dient[2].

Der Autor steht in keinerlei Abhängigkeitsverhältnis zum Herausgeber des BMEcat-2005-Standards oder damit verbundenen Organisationen oder Gremien. Die im vorliegenden Buch nach bestem Wissen und Gewissen getroffenen Aussagen geben also alleine die persönliche Meinung des Autors wieder.

1.4 Konventionen

Zitate aus der BMEcat-Spezifikation sind kursiv geschrieben und mit einem Rahmen umgeben:

"Dies ist ein Zitat aus der BMEcat-2005-Spezifikation."

XML-Fragmente sind mit einem hellgrauen Hintergrund hinterlegt:

<ELEMENT>der Inhalt eines Elements</ELEMENT>

Um Einzelheiten eines XML-Fragments gezielt hervorzuheben, wird Fettdruck verwendet, zum Beispiel:

< ELEMENT >der Inhalt eines Elements</ ELEMENT >

Hinweis:
Meistens wird bei der Angabe von XML-Fragmenten auf die Angabe der XML-Deklaration verzichtet. Tatsächlich muss eine BMEcat-Datei immer mit einer geeigneten XML-Deklaration beginnen.

1.5 Aufbau des Buches

Nach der Einleitung steckt das Kapitel Katalogaustauschformate und BMEcat den Rahmen für den Einsatz von BMEcat-2005 ab.

Danach folgt der eigentliche Hauptteil BMEcat-2005-Dokumente des Buches, bei dem es um das Dokumentenformat selbst geht. Der Hauptteil ist dreigeteilt: In dem ersten Teil werden einige grundlegende Konzepte von BMEcat-2005 dargestellt. Der zweite Teil behandelt Aufbau und Struktur von BMEcat-2005-Dokumenten. Der dritte Teil geht noch detaillierter auf Einzelheiten ein; es werden verschiedene Bausteine von BMEcat-2005 besprochen.

Die einzelnen Themen des Hauptteils werden häufig nach einem bestimmten Schema abgehandelt: Der Darstellung eines Sachverhaltes folgt ein konkretes BMEcat-2005-Beispiel. Anschließend wird das Beispiel bewertet und diskutiert. Der Bezugspunkt ist dabei immer die BMEcat-2005-Spezifikation. Gelegentlich wird zum Schluss noch auf ein anderes, mit dem Thema in Zusammenhang stehendes Kapitel hingewiesen.

1.6 Die Spezifikation

Die BMEcat-2005-Spezifikation ist aufgeteilt in fünf Dokumente:

- Hauptdokument[3]
- Modul Klassifikationssysteme, Kataloggruppensysteme und Merkmalssysteme[4]
- Modul Preisformeln[5]
- Modul Produktkonfiguration[6]
- Modul Integrated Procurement Point (IPP)[7]

Ergänzend zur Spezifikation wird eine XML-Schema-Datei bereitgestellt[8].

Die Inhalte der fünf Module sind nicht überschneidungsfrei: Manche Bestandteile der Spezifikation tauchen in mehreren Modul-Dokumenten auf. Die Intention der Herausgeber war es, den Nutzern die Handhabung zu erleichtern; falls nur Teilbereiche der Spezifikation benötigt werden, soll nicht die gesamte Spezifikation durchzuarbeiten sein.

Nach den Erfahrungen des Autors bei der Implementierung seines Validierungswerkzeuges, kann sich die redundante Aufteilung in mehrere Dokumente jedoch auch negativ auf die Handhabung auswirken: Tauchen Elemente in anderen Spezifikationsdokumenten erneut auf, ist zu prüfen, ob die Elemente vollkommen identisch sind, oder ob es geringfügige Unterschiede gibt, die zu beachten sind.

Auf eine Nachfrage des Autors im Jahre 2015 bei der herausgebenden Organisation BME e. V. wurde eine existierende Fehlerliste zu BMEcat-2005 erwähnt. Eine Fehlerliste ist also intern vorhanden, wird jedoch bislang nicht veröffentlicht. Mangels Veröffentlichung kann die Fehlerliste leider nicht berücksichtigt und zur Validierung herangezogen werden.

Wenn in der Folge von "der Spezifikation" die Rede ist, ist in Abhängigkeit des Zusammenhangs entweder die Gesamtheit der Module oder nur das Hauptdokument gemeint.

1.7 Validierung

Im Hauptteil des Buches geht es im wesentlichen um die Klärung, ob betrachtete Dokumente als korrekte BMEcat-2005-Dokumente zu bestätigen sind oder nicht. Die folgenden Abschnitte verdeutlichen, was der Autor unter diesem Klärungsprozess versteht.

1.7.1 Begriffe

Der Vorgang der Klärung wird im vorliegenden Buch als „ Validierung “ bezeichnet[9], gelegentlich auch als „ Prüfung “. Auf den ersten Blick erscheint möglicherweise der Begriff „ Verifikation “ angemessener[10]. Der Begriff Verifikation wird jedoch hier vermieden, da er häufig im Sinne eines (mathematischen) Beweises verwendet wird. Ein solcher Beweis ist jedoch schwerlich bei der BMEcat-2005-Spezifikation zu führen, denn die Spezifikation enthält auch nicht-formale Anteile in Textform.

Führt der Klärungsprozess bei einem BMEcat-2005-Dokument zu keinem Fehler, ist das Dokument also fehlerfrei und als BMEcat-Dokument anzuerkennen, wird es hier auch kurz als „ valide “, „ gültig “ oder „ Standard-konform “ bezeichnet.

Wird in dem Dokument mindestens ein Fehler gefunden, ist es "nicht valide", "invalide" oder "ungültig"[11].

1.7.2 Die Anforderungen zur BMEcat-2005-Validierung

Zur Validierung eines BMEcat-2005-Dokumentes sind die und nur die Anforderungen aus allen Modulen der BMEcat-2005-Spezifikation[12] als Maßstab zu nehmen. Insbesondere bedeutet diese Sichtweise auch, dass die aus der Spezifikation abgeleitete, und ergänzend zur Spezifikation veröffentlichte XML-Schema-Datei[13] nach Meinung des Autors keine maßgebliche Referenz bei der Validierung darstellt.

1.7.3 Die Rolle der XML-Schema-Datei

Die Nutzung der ergänzenden XML-Schema-Datei kann Hilfsweise zur Plausibilisierung der Gültigkeit verwendet werden. Ein BMEcat-2005-Dokument, das nach der XML-Schema-Datei ordnungsgemäß aufgebaut ist, bietet jedoch keine Gewähr für ein positives Ergebnis der Validierung.

Das gilt besonders für den Fall, dass sich die Spezifikation und die XML-Schema-Datei widersprechen[14].

Ein Beispiel, in dem sich Spezifikation und XML-Schema-Datei unterscheiden, bietet das BMEcat-Element LEADTIME:

Das Element PRODUCT_PRICE enthält kein Kindelement LEADTIME[15]. Das korrespondierende Element ARTICLE_PRICE von BMEcat-1.2 enthält ebenfalls kein LEADTIME-Element[16]. Dagegen enthält in BMEcat-2005 aus Kompatibilitätsgründen zugelassene Element ARTICLE_PRICE das Kindelement LEADTIME. Die Spezifikation für BMEcat-2005 beschreibt das Element ARTICLE_PRICE nicht näher. Allerdings erlaubt die Spezifikation bei übernommenen Elementen der Vorgängerversion nur Ergänzungen für Kindelemente, die es auch im korrespondierenden Element neueren Version 2005 gibt[17].

Im Widerspruchsfall wird hier grundsätzlich davon ausgegangen, dass die Spezifikation maßgeblich ist, und die XML-Schema-Datei falsch.

Anzumerken ist, dass die XML-Schema-Datei nicht alle Anforderungen aus der Spezifikation enthält; die XML-Schema-Datei ist also unvollständig. Insbesondere sind viele Abhängigkeiten und Referenzen zwischen unterschiedlichen Bereiches eines BMEcat-2005-Dokuments nicht in der XML-Schema-Datei abgebildet. Ebenso finden viele im Text der Spezifikation formulierte, zusätzliche Bedingungen oder Einschränkungen keinen Widerhall in der XML-Schema-Datei.

Nachfolgend zwei Beispiele als Belege der Behauptung:

- Auf Seite 113 des Hauptdokuments der Spezifikation[18] heißt es:

"Die (Basis-)Artikelnummer muss auch beim Einsatz von Varianten oder Konfigurationen für sich allein genommen bereits eindeutig sein."

Diese Bedingung ist nicht in der XML-Schema-Datei zu finden.

- Laut Seite 122 des Hauptdokuments der Spezifikation darf in den Produkt-Details das Element PRODUCT_STATUS je Produkt mehrfach vorkommen. Das Element besitzt jeweils ein Pflichtattribut type. Das Attribut type darf nicht mehrfach mit dem gleichen Wert auftreten. Diese Einschränkung ist nicht in der XML-Schema-Datei abgebildet.

1.7.4 Die Auslegung der Spezifikation

1.7.4.1 Allgemeines

Für den Autor stellt die BMEcat-2005-Spezifikation in Gestalt der fünf Spezifikationsdokumente[19] die alleinige Basis zur Beurteilung dar, ob es sich bei einem geprüften Dokument um ein nach BMEcat-2005 valides Dokument handelt oder nicht.

Die Interpretation der Spezifikation stellt sich im Einzelfall nicht immer als klar und eindeutig heraus. Deshalb dienen die nachfolgenden Aussagen dem Autor als Richtschnur zur Auslegung der Spezifikation:

Alles, was nicht ausdrücklich von der Spezifikation verboten ist, ist erlaubt, und bewegt sich daher innerhalb des Standards. Fehlen also konkretisierende Angaben, oder sind Spielräume zur Interpretation vorhanden, dürfen die Spielräume voll ausgenutzt werden.

Widersprüchliche oder fehlerhafte Stellen in der Spezifikation führen bei der Abbildung in ein BMEcat-2005-Dokument zu einem invaliden, nicht standard-konformen Dokument. Ausnahme: Wenn ein Beispiel in der Spezifikation gegen die Spezifikation verstößt. In diesem Fall wird in der Regel das Beispiel als falsch gewertet, die dagegen stehende Anforderung der Spezifikation als maßgebend.

Anforderungen, die nicht explizit in der Spezifikation formuliert sind, sich aber implizit Schlussfolgern lassen, werden in der Regel als Anforderung der Spezifikation aufgefasst. Die endgültige Beurteilung ist jedoch eine Einzelfallentscheidung.

1.7.4.2 Textauslegung

Am schwierigsten auszulegen sind Anforderungen, die sich aus Textpassagen ergeben. Hier ist eine Einzelfallentscheidung erforderlich. Ein diesbezügliches Beispiel stellt die umfangreiche textuelle Beschreibung der Spezifikation zum Element PRODUCT_FEATURES dar[20].

Die generelle Problematik ist hierbei, dass die Standardisierung gerade den Zweck hat, ein einheitliches Anforderungssystem zu formulieren, das Missverständnisse vermeidet. Anforderungen sollten also einfach, klar und präzise formuliert sein, damit unterschiedliche Anwender die gleichen Anforderungen aus der Spezifikation ablesen. Beim vorherigen Beispiel dürfte jedoch die einheitliche Auslegung nach Meinung des Autors nicht sichergestellt sein.

Aussagen in Textform werden vom Autor teilweise umgangssprachlich, und nicht entsprechend der formalen Logik interpretiert, wenn anzunehmen ist, dass damit der intendierten Bedeutung eher gerecht wird. Als Beispiel diene folgende Aussage:

"Ein Dokument ist dann BMEcat-konform, wenn es alle Felder in der angegebenen Reihenfolge enthält."

Es handelt sich um eine Aussage der Form "Wenn A dann B". Gemäß formaler Logik tritt B ein, wenn A erfüllt ist. Wenn A nicht erfüllt ist, kann B eintreten oder auch nicht. Doch letzteres dürfte mit obiger Aussage nicht gemeint sein. Vermutlich ist eher im umgangssprachlichen Sinne gemeint, dass B nicht eintritt, wenn A nicht der Fall ist. Für das Beispiel dürfte damit gemeint sein, dass das Dokument nicht BMEcat-konform ist, wenn die Felder nicht in der angegebenen Reihenfolge aufgelistet werden.

Ein valides BMEcat-2005-Dokument muss nicht zwingend sinnvolle Werte aufweisen. Die inhaltliche Korrektheit ist also nicht schon durch die Standard-Konformität alleine sichergestellt.

1.7.5 Die Bedeutung der Zertifizierung

Es gibt die Möglichkeit, mittels Zertifizierung ein offizielles Prüfsiegel über die Konformität zum BMEcat-2005-Standard zu erwerben[21]. Die Zertifizierung bezieht sich allerdings nur auf ein ganz bestimmtes BMEcat-2005-Dokument.

Eine derartige Zertifizierung erscheint nur praktikabel, falls es sich um die Übertragung eines gesamten Produktkataloges handelt, und sich der Produktkatalog eines Unternehmens sehr selten ändert.

Ein etwas abgewandelter Produktkatalog ist nicht automatisch auch valide. Um sicherzugehen, muss jedes neu im BMEcat-2005-Format erstellte oder modifizierte Dokument eigens validiert werden.

Hilfreicher wäre es, wenn die Zertifizierung einen Schritt weiter ginge, und Software-Werkzeuge zertifizierte, die BMEcat-2005-Dokumente validieren. Doch aufgrund der hohen Komplexität des BMEcat-2005-Standards wäre dieses Unterfangen mit einem wesentlich höherem Aufwand verbunden als mit dem derzeitigem Angebot.

Bei der Zertifizierung von BMEcat-2005-Dokumenten ist ein weiterer wesentlicher Gesichtspunkt zu berücksichtigen: Wie im weiteren Verlauf des Buches anhand einiger Beispiele gezeigt wird, erscheint die BMEcat-2005-Spezifikation derzeit nicht völlig klar, widerspruchsfrei und fehlerfrei. Welche Aussagekraft und welchen Nutzen besitzt unter diesem Aspekt eine Zertifizierung?

2 Katalogaustauschformate und BMEcat

2.1 Fachlicher Kontext

Der Industriestandard BMEcat-2005 formuliert die Anforderungen an ein elektronisches Austauschformat für Produktkataloge. Wesentlicher Bestandteil von Produktkatalogen sind Produktdaten[22].

Produktdaten[23] fallen nicht nur innerhalb der Unternehmen zur Verwaltung an. Zusammenstellungen von Produktdaten in Form von Produktkatalogen werden auch zwischen Unternehmen ausgetauscht. Bei der Betrachtung elektronischer Geschäftsprozesse spielt der Katalogdatenaustausch insbesondere auf der Einkaufsseite und der Verkaufsseite eine große Rolle. Ebenso sind Kataloge bei elektronischen Marktplätzen ein wichtiger Bestandteil geworden. Auch wenn es um die An- oder Einbindung von Warenwirtschaftssystemen, Produktinformationssystemen (kurz mit dem Akronym PIM bezeichnet) oder Online-Shop-Systemen geht, erleichtern standardisierte Katalogaustauschformate den Unternehmen die quantitativ und qualitativ herausfordernden Aufgabenstellungen.

Zum Verständnis der größeren Zusammenhänge im E-Business-Bereich wird auf /eBiz/ verwiesen; für weitere Einblicke in das Katalogdatenmanagement einschließlich alternativer Austauschformate auf /KdmB2B/. Einen ersten Überblick über die Thematik erhalten Interessierte zum Beispiel unter /Katalog/.

2.2 Die Organisation hinter BMEcat

Der Bundesverband Materialwirtschaft, Einkauf und Logistik e. V. (BME) besitzt alle Rechte an BMEcat. Die Mitglieder des Fachverbandes gehören nach eigenen Angaben allen Branchen und Sektoren an und decken einen beträchtlichen Anteil des deutschen Bruttoinlandsproduktes ab[24].

2.3 Lizenzen

Das Katalogaustauschformat BMEcat-2005 darf kostenfrei genutzt werden. Für Details der Lizenzierung wird auf /BMEliz/ sowie auf /BMEvor/ verwiesen.

2.4 Verbreitung

BMEcat-2005 scheint vor allem im deutschsprachigen Raum eine große Verbreitung zu besitzen. Darauf deuten zum Beispiel die Suchergebnisse bei Internet-Suchmaschinen oder auch Aussagen wie bei / BMEcat / hin. Jenseits dieser qualitativen Aussage sind jedoch kaum belastbare quantitative Fakten erhältlich.

Bei einer Anfrage an den Fachverband BME e. V. im Jahr 2015 wurde der Autor auf eine Studie aus dem Jahre 2010 verwiesen[25]: Die Berlecon-Studie basiert auf einer Befragung von über eintausend deutschen Anwenderunternehmen unterschiedlicher Branchen und Unternehmensgrößen. Demnach hat BMEcat bei XML-basierten Standards in verschiedenen Branchen insbesondere bei größeren Unternehmen eine hohe Bekanntheit, Akzeptanz und Verbreitung erreicht.

Eine kurze Internet-Recherche des Autors vermittelt den Eindruck, dass BMEcat-2005 vorwiegend genutzt wird, um komplette Kataloge auszutauschen; die vorgesehenen Transaktionen für Produkt- oder Preisaktualisierungen werden dagegen offenbar kaum genutzt.

Neben den Produktkatalogen selbst, werden manchmal Klassifikationssysteme in BMEcat-Dokumente integriert. Andererseits gibt die Internet-Recherche keine Hinweise, dass BMEcat-2005 verwendet wird, um weitere optionale Bestandteile wie etwa Produktkonfigurationen, Preisformeln oder Anwendungen für Integrated Procurement Points abzubilden.

2.5 BMEcat-Versionen

BMEcat wurde zuerst 1999 in der Version 1.0 sowie im Jahr 2000 in der Version 1.01 veröffentlicht[26]. Diese Version erlaubt die Übertragung einsprachiger Produktkataloge sowie Aktualisierungen von Produkten oder Produktpreisen.

In der BMEcat-Version 1.2 aus dem Jahr 2000 werden insbesondere Möglichkeiten zum Austausch von Klassifikationssystemen und Produktvarianten ergänzt[27].

Die BMEcat-2005-Version aus dem Jahr 2005 bringt gegenüber der Vorgängerversion vielfältige Verbesserungen und Erweiterungen: Mehrsprachigkeit und Multi-Lieferanten-Kataloge können seit dieser Version abgebildet werden. Neben Verbesserungen bei der Übertragung von Klassifikationssystemen werden insbesondere Formeln, Produktkonfiguration und Integrated Procurement Points unterstützt[28].

Eine etwas ergänzte Version 2005.1 (advanced) entsteht seit einigen Jahren in Zusammenarbeit mit eCl@ss e. V.[29] um aktuelle Versionen des eCl@ss-Klassifikationsstandards besser in BMEcat-2005 abbilden zu können. Die offizielle Freigabe steht jedoch aus[30]. Andererseits beruft sich eCl@ss bereits auf BMEcat-2005.1[31], und es liegen bereits mehrere Richtlinien zur Einbettung von eCl@ss in BMEcat-2005.1 vor[32].

3 BMEcat-2005-Dokumente

3.1 XML als technische Basis

3.1.1 Einführung

BMEcat setzt seit dem Erscheinen der ersten Version auf das damals noch relativ neue XML-Datenformat[33]. Im Gegensatz zu älteren, datensatzorientierten Formaten wie EDI oder DATANORM[34] lassen sich mit XML hierarchische Datenstrukturen einfach und flexibel beschreiben. Andererseits berücksichtigt BMEcat bislang neuere Ansätze, wie etwa das Semantische Web[35], nicht.

XML-Dokumente dürfen zur Ausweisung der Aufbaustruktur optional auf -Dateien oder Dokumenttypdefinitionen (DTD) verweisen. Diese Option wird in der Folge nicht weiter betrachtet, da einerseits die XML-Schema-Datei für BMEcat-2005 nicht alle Anforderungen der Spezifikation abdeckt, andererseits - wie angegebene Beispiele zeigen werden - die ergänzend zur Spezifikation bereitgestellte XML-Schema-Datei nicht vollständig fehlerfrei ist.

3.1.2 XML-Deklaration

Ein BMEcat-Dokument kann nur gültig sein, wenn es auch wohlgeformt im XML-Sinne ist. Das bedeutet insbesondere, dass jedes gültige BMEcat-Dokument in der ersten Zeile mit einer XML-Deklaration[36] beginnt. In der einfachsten Form sieht die XML-Deklaration wie folgt aus:

<?xml version="1.0"?>
<!-- ... hier folgt der Rest des Dokuments ... -->

Durch Ergänzung des encoding -Attributs wird in der XML-Zeile der Zeichensatz für das gesamte restliche Dokument festgelegt. Das folgende Beispiel verwendet den Zeichensatz ISO-8859-1:

<?xml version="1.0" encoding="ISO-8859-1"?>
<!-- ... hier folgt der Rest des Dokuments ... -->

Bei fehlender encoding -Angabe wird als Zeichensatz UTF-8[37] angenommen.

3.1.3 XML-Entitäten

Einige Zeichen sind für die XML-Syntax reserviert, und dürfen daher nicht unverändert in den übrigen Inhalten einer XML-Datei - und damit auch nicht in BMEcat-Dokumenten - auftauchen[38].

Zum Beispiel ist das folgende Fragment fehlerhaft:

<ADDRESS><NAME>Huber & Co. GmbH</NAME></ADDRESS>

Das Kaufmanns-Und muss geeignet repräsentiert werden, um korrektes XML zu erhalten. Das vorausgehende Beispiel ist daher zu korrigieren:

<ADDRESS><NAME>Huber &amp; Co. GmbH</NAME></ADDRESS>

3.1.4 Groß- und Kleinschreibung

XML unterscheidet zwischen Groß- und Kleinschreibung. BMEcat-2005 definiert die verwendeten XML-Elemente in der Spezifikation groß geschrieben. Daher sind klein geschriebene BMEcat-2005-Elemente nicht erlaubt.

Falsch ist also zum Beispiel:

< name >Huber GmbH</ name >

Ebenso falsch ist:

< Name >Huber GmbH</ Name >

Korrekt ist dagegen:

< NAME >Huber GmbH</ NAME >

3.1.5 Reihenfolge der XML-Elemente

Die Spezifikation trifft eine Festlegung zur Reihenfolge von BMEcat-2005-Elementen[39]:

"Ein Katalogdokument ist dann BMEcat®-konform, wenn es alle Muss-Felder und keine anderen als die in der Spezifikation definierten Kann-Felder in der angegebenen Reihenfolge [...] enthält."

Das folgende, im Internet gefundene, Beispiel enthält kein korrektes BMEcat-2005, denn die Elemente ORDER_UNIT und CONTENT_UNIT sind nicht in der richtigen Reihenfolge dargestellt:

Abbildung in dieser Leseprobe nicht enthalten

Bei einem ausgelassenen Element ist ebenfalls keine korrekte Reihenfolge mehr gegeben. Ein Beispiel aus der Spezifikation[40] illustriert den Fall:

Abbildung in dieser Leseprobe nicht enthalten

Laut Spezifikation[41] darf unter dem CONTACT_DETAILS - Element nur ein -Element auftreten (endet am Ende auf den Buchstaben „ S “). Das EMAILS-Element wiederum muss mindestens ein EMAIL -Element enthalten. Das EMAIL -Element darf jedoch nicht direkt unter CONTACT_DETAILS auftreten. In der Konsistenz bedeutet das, das Spezifikationsbeispiel ist nicht korrekt.

Die Anforderung zur Einhaltung einer bestimmten Reihenfolge von Elementen beinhaltet auch die Unveränderlichkeit der Elementnamen; ähnlich geschriebene Elementnamen führen zu einem ungültigen BMEcat-2005-Dokument. Das folgende Beispiel aus der Spezifikation[42] ist daher falsch:

Abbildung in dieser Leseprobe nicht enthalten

Der Elementname AGREEMENT_DESC weicht von dem auf derselben Seite der Spezifikation festgelegten Elementnamen AGREEMENT_DESCR ab (am Ende des Elementnamens fehlt der Buchstabe „ R “).

Abschließend sei noch auf einen besonderen Fall der Element-Reihenfolge bei BMEcat-2005 hingewiesen – nämlich, wenn es um die Angabe von E-Mail-Adressen sowie den dazugehörigen öffentlichen Schlüsseln geht[43]. Ziel ist es, mehrere E-Mail-Adressen anzugeben. Zu jeder E-Mail-Adresse sollen optional ein oder mehrere öffentliche Schlüssel mit angegeben werden können. Eine Umsetzung des Schemas im Sinne von BMEcat-2005 könnte beispielhaft zum nachfolgenden Fragment führen:

Abbildung in dieser Leseprobe nicht enthalten

Das Fragment ist im Sinne von BMEcat-2005 grundsätzlich in Ordnung. Eine mehrfach abwechselnde Abfolge der Elemente EMAIL und PUBLIC_KEY ist in dieser Form unüblich, jedoch festlegbar. Doch: Was genau ist die Aussagekraft des Fragments? Gemäß Spezifikation[44] bezieht sich ein Schlüssel in einem PUBLIC_KEY -Element auf „die E-Mail“. Das vorausgehende Beispiel enthält jedoch zwei E-Mails. Es lässt sich nur vermuten, dass sich ein Schlüssel auf die unmittelbar vorausgehende E-Mail-Adresse bezieht. Die Spezifikation bezieht zu dem Punkt keine Stellung. Letztendlich bleibt die Zuordnung mangels klarer Vorgaben offen. Das PUBLIC_KEY -Element ist daher immer mit Bedacht zu verwenden.

3.1.6 Länge der XML-Element-Inhalte

BMEcat-2005 legt zu den Elementen und Attributen fest, wie viele Zeichen die Inhalte maximal umfassen dürfen.

Zum Beispiel darf das DEPARTMENT-Element maximal 50 Zeichen beinhalten[45]. Die Spezifikation selbst bietet ein Beispiel zur Verwendung der Elemente an[46]:

Abbildung in dieser Leseprobe nicht enthalten

Tatsächlich weist der Inhalt des DEPARTMENT -Elements etliche Zeichen mehr auf. Das Beispiel der Spezifikation überschreitet also die Vorgabe der eigenen Spezifikation; es ist nicht konform zu BMEcat-2005.

Im Falle des Elementes URL ist jedoch bereits fraglich, aus wie vielen Zeichen das Element bestehen darf. So wird einerseits eine maximale Elementlänge von 255 Zeichen bestimmt[47]. Andererseits wird auf derselben Seite erwähnt, dass die Länge des Elements in der aktuellen Version von 100 auf 250 Zeichen heraufgesetzt wurde. Die Zahlen 255 und 250 unterscheiden sich. Welche der beiden Zahlen soll gelten? Vermutlich darf das Element auf 255 Zeichen anwachsen. Sicherheitshalber sollte ein Limit von 250 Zeichen eingehalten werden, um auf der sicheren Seite zu bleiben.

3.2 Kompatibilität zur Vorgängerversion BMEcat-1.2

Wie bereits beim vorhergehenden Versionssprung von Version 1.01 auf 1.2, versucht BMEcat-2005 die Kompatibilität mit der BMEcat-Vorgängerversion 1.2 zu erreichen[48]:

"BMEcat® 2005 ist in dem Sinne voll abwärtskompatibel zu BMEcat® 1.2, dass zu BMEcat® 1.2 konforme Katalogdokumente auch konform zu BMEcat® 2005 sind."

Wie in der Folge dargestellt, wird die Kompatibilität durch eine Reihe von Einschränkungen und Besonderheiten der Spezifikation aufgeweicht.

3.2.1 Einschränkungen

Die obige generelle Aussage der Spezifikation zur Kompatibilität von BMEcat-2005 zur Vorgängerversion BMEcat-1.2 trifft zwar für den Großteil der Bestandteile von BMEcat zu, ist in strenger Auslegung jedoch nicht korrekt.

Zur Verdeutlichung des Sachverhalts dienen drei Beispiele. Die ersten beiden Beispiele werden anhand des gleichen BMEcat-1.2-Dokuments erläutert. Das Dokument enthält die Mindestangaben für den Kopfbereich sowie eines Merkmalsgruppensystems und eines Produktes.

3.2.1.1 Einsprachiger Katalog

BMEcat-Dokumente der Version 1.2 beherrschen nur einsprachige Kataloge. Die Sprache wird mittels LANGUAGE-Element im Kopfbereich angegeben. Das nachfolgende BMEcat-Dokument der Version 1.2 ist in der deutschen Sprache (Sprach-Kürzel deu) abgefasst:

Abbildung in dieser Leseprobe nicht enthalten

Da keine weiteren Sprachen im BMEcat-1.2-Dokument verwendet werden, reicht die Sprach-Angabe im Kopfbereich aus. Es sind keine weiteren Sprach-Festlegungen im restlichen Dokument erforderlich. Alle sprachabhängigen Inhalte sind in deutscher Sprache abzufassen. Insbesondere sind zum Element DESCRIPTION_SHORT keine ergänzenden Angaben erforderlich.

BMEcat-2005 erlaubt jedoch mehrsprachige Dokumente (mehr dazu in Kapitel 3.3.6). Im Kopfbereich müssen dazu alle verwendeten Sprachen mit LANGUAGE-Elementen angegeben werden. Im restlichen Dokument sind die sprachabhängigen Elemente für jede Sprache mit dem neu eingeführten Attribut lang anzugeben.

Die Verfahrensweise für einsprachige Kataloge ist in BMEcat-2005 wie folgt festgelegt[49]:

"Einsprachige Kataloge: In dem Element wird die verwendete Sprache angegeben. Wird zusätzlich das default-Attribut gesetzt, so kann anschließend bei allen sprachabhängigen Informationen auf die Angabe der Sprache verzichtet werden (Default-Sprache)."

Da es bei BMEcat Version 1.2 kein Attribut default zum Element LANGUAGE gibt, ist es im vorausgehenden Beispiel auch nicht enthalten.

Im Gegensatz zur BMEcat-Version 1.2 verlangt die Spezifikation bei BMEcat-2005 entweder die Ergänzung des default -Attributs im LANGUAGE-Element des Kopfbereiches oder aber die durchgehende Angabe des lang-Attributes in sprachabhängigen Elementen. Im Beispiel wird das sprachabhängige Element DESCRIPTION_SHORT verwendet. Dieses Element muss mit dem Attribut lang gekennzeichnet werden. In BMEcat-2005 lautet eine gültige Darstellung für das Element:

Abbildung in dieser Leseprobe nicht enthalten

Das obige Beispiel enthält jedoch weder ein lang -Attribut (das Attribut gibt es in BMEcat Version 1.2 ebenfalls nicht), noch ein default -Attribut. Daher ist das Beispiel-Dokument konform zu BMEcat-1.2, nicht aber zu BMEcat-2005.[50]

3.2.1.2 Element FEATURE_SYSTEM

Das zweite Beispiel verwendet das gleiche Dokument wie im vorherigen Beispiel, fokussiert jedoch auf das Element FEATURE_SYSTEM.

Mit dem Element FEATURE_SYSTEM werden in BMEcat Version 1.2 Merkmalsgruppensysteme beschrieben.

Abbildung in dieser Leseprobe nicht enthalten

Das Element FEATURE_SYSTEM wird zwar bei BMEcat-2005 noch erwähnt, ist jedoch als verboten gekennzeichnet; es darf nicht mehr verwendet werden[51].

Die Verwendung des Elements FEATURE_SYSTEM ist ein zweiter Grund, warum das vorausgehende Dokument zwar konform zu BMEcat Version 1.2 ist, nicht jedoch zu BMEcat-2005.

3.2.1.3 Eingeschränkte Wertebereiche

Das dritte Beispiel für die Nicht-Kompatibilität von BMEcat-1.2 und BMEcat-2005 ist eher theoretischer Natur.

BMEcat kennt bereits in der Version 1.2 das Element CLASSIFICATION_GROUP mit dem Attribut level. Das Attribut enthält die Hierarchieebene der Klassifikationsgruppe. Ein passendes XML-Fragment könnte zum Beispiel wie folgt aussehen:

Abbildung in dieser Leseprobe nicht enthalten

In dem Beispiel ist -2 als Wert des Attributs level eingetragen. Die Spezifikation für die Version 1.2 erlaubt negative level -Werte ausdrücklich[52]. Daher ist das XML-Fragment mit der Version 1.2 von BMEcat vereinbar. Ob eine negative Hierarchieebene einen Sinn ergibt oder nicht, ist hier nicht von Belang.

Beim Übergang zur Version 2005 von BMEcat wurde der Wertebereich des level -Attributs eingeschränkt: Erlaubt sind nur noch positive ganze Zahlen oder die Null[53]. Wenn im level -Attribut ein negativer Wert steht, ist der Wert nicht mehr von der Spezifikation für BMEcat-2005 abgedeckt. Das XML-Fragment ist damit in Version 1.2 von BMEcat gültig, in der Version 2005 jedoch nicht mehr. Mit anderen Worten: In diesem Fall ist die Kompatibilität zwischen den BMEcat-Versionen 1.2 und 2005 durchbrochen.

3.2.2 Besonderheiten

Die Kompatibilität von BMEcat-2005 mit der Vorgängerversion BMEcat-1.2 bedeutet nicht nur, dass gültige BMEcat-1.2-Dokumente als Ganzes auch in BMEcat-2005 als gültig gewertet werden. Es wurden für den Übergang eine Reihe zusätzlicher Regelungen geschaffen, die die Komplexität der BMEcat-2005-Spezifikation erhöht.

3.2.2.1 Umbenennung von Elementnamen

Der Übergang auf die neuere BMEcat-Version 2005 wurde insbesondere genutzt, um einen Teil der Elementnamen besser an internationale Gepflogenheiten anzupassen[54]:

- Der Bestandteil ARTICLE wurde in den BMEcat-Elementen geändert nach PRODUCT.
- Der Bestandteil AID (Artikelnummer-Identifikation) wurde in den BMEcat-Elementen geändert nach PID (Produkt-Identifikation).
In beiden Fällen bleiben die übrigen Bestandteile des Elementnamens unverändert erhalten.
Zwei Beispiele sollen den Vorgang verdeutlichen:
- Das Element ARTICLE_DETAILS wird zu PRODUCT_DETAILS.
- Das Element SUPPLIER_AID wird zu SUPPLIER_PID.

3.2.2.2 Weiterverwendbarkeit alter Elemente

Bei der Weiterentwicklung von der BMEcat-Version 1.2 zur Version 2005 wird ein Teil der alten Elemente aus Version 1.2 unverändert oder mit Erweiterungen weiterverwendet[55]:

Um die Abwärtskompatibilität zu Version 1.2 zu erhalten, sind die Elemente in der alten Namensgebung trotzdem noch enthalten

Manche Elemente werden umbenannt, haben sich jedoch in ihrer Bedeutung nicht verändert. Andere Elemente fallen in zukünftigen Versionen weg und werden in Version 2005 durch einen modifizierten Mechanismus ersetzt.

Zum Beispiel wird in den Kopfdaten der Lieferant nicht mehr direkt durch Angabe des Elements SUPPLIER_NAME benannt, sondern eine an einer anderen Stelle des Dokuments eine Partei (PARTY) mit einer eindeutigen ID (PARTY_ID) festgelegt, auf die zur Bestimmung des Lieferanten nur noch per Element SUPPLIER_IDREF referenziert wird:

Abbildung in dieser Leseprobe nicht enthalten

Es bleibt den Nutzern der BMEcat-Version 2005 jedoch freigestellt, weiterhin den alten Mechanismus zu verwenden, also etwa wie folgt:

Abbildung in dieser Leseprobe nicht enthalten

3.2.2.3 Gemischte Verwendung von alten und neuen Elementen

Wie im vorhergehenden Kapitel 3.2.2.2 besprochen, besitzen Anwender an vielen Stellen der Spezifikation von BMEcat-2005 die freie Wahl, entweder das aktuelle Element von BMEcat-2005 oder alternativ das alte Element der BMEcat-Vorgängerversion 1.2 zu einzusetzen. Die Entscheidung an einer Stelle der Spezifikation für alt oder neu ist unabhängig von den Entscheidungen an den anderen Stellen. Jedenfalls fordert die Spezifikation keine durchgehend einheitliche Festlegung für eine der beiden Alternativen. Das bedeutet: Elemente der Vorgängerversion 1.2 und der aktuellen Version 2005 dürfen zusammen eingesetzt werden, ohne die Validität eines BMEcat-2005-Dokuments zu gefährden.

Hier ein Beispielfragment, in dem drei aufeinander folgende Produkte abwechselnd zur Bezeichnung einer Europäischen Artikelnummer[56] das alte Element EAN sowie das neue Element INTERNATIONAL_PID verwenden[57]:

Abbildung in dieser Leseprobe nicht enthalten

3.2.2.4 Gemischte Verwendung alter und neuer Mechanismen

Da Elementfolgen auch Mechanismen beschreiben können, betrifft die wahlfreie Abfolge von alt und neu auch Mechanismen.

Zur Verdeutlichung dient das folgende Beispiel, das gültiges BMEcat-2005 darstellt:

Abbildung in dieser Leseprobe nicht enthalten

Das Beispiel verwendet für die Angabe des Einkäufers (BUYER) den alten Mechanismus von BMEcat-1.2 mit einfacher Angabe eines sprachunabhängigen Namens. Innerhalb des gleichen Dokuments wird der Lieferant (SUPPLIER) nicht ebenfalls direkt durch Angabe des Namens festgelegt, sondern durch den neuen Mechanismus von BMEcat-2005, der auf erst einmal auf eine Partei (PARTY) verweist, und dort den Lieferanten näher bestimmt.

3.2.2.5 Anreicherung von alten Elementen mit neuen Kindelementen

Zur Sicherstellung der Kompatibilität zur Vorgängerversion 1.2 setzt BMEcat in der Version 2005 einen Kunstgriff ein[58]:

Um die Abwärtskompatibilität zu Version 1.2 zu erhalten, sind die Elemente in der alten Namensgebung trotzdem noch enthalten. Sie von der Struktur weitestgehend identisch zu den neuen "Produkt"-Elementen und enthalten auch die meisten neuen Unterelemente. Aufgrund der strukturellen und inhaltlichen Übereinstimmung, werden daher die Unterelemente von ARTICLE nicht nochmals erläutert, um die Dokumentation nicht unnötig zu vergrößern.

Alte Elemente dürfen also nicht nur die in der Vorgängerversion zugelassenen Kindelemente enthalten, sondern auch neue Elemente der Version 2005 auf. Letztendlich werden an einigen Stellen alte und neue Elemente vermischt.

Leider bleibt die Spezifikation zu den Einzelheiten vage: Zum Versionsübergang ist die Rede von "weitestgehend identisch" und "die meisten". Diese Formulierungen führen zu unpräzisen und unvollständigen Stellen in der Spezifikation. Zur Klärung der Lücken ist als verbliebener Quelle auf die XML-Schema-Datei von BMEcat-2005 zurückzugreifen. Wie an früherer Stelle festgestellt wurde, ist auf die XML-Schema-Datei jedoch kein Verlass[59].

Der Effekt der Vermischung von Elementen der beiden BMEcat-Versionen 1.2 und 2005 wird anhand der Kindelemente der einander entsprechenden Elemente PRODUCT und ARTICLE zur Transaktion T_NEW_CATALOG in Tabelle 1 erläutert.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 1: Artikelinhalte der BMEcat-Versionen

Die linke der drei Tabellenspalten zeigt die in der aktuellen Version 2005 von BMEcat erwarteten Produkt-Kindelemente. In der rechten Spalte ist der Stand für die Vorgängerversion 1.2 von BMEcat zu sehen. Der Vergleich beider Spalten zeigt, dass in BMEcat-2005 fünf neue Elemente ergänzt wurden. Von den übrigen acht Elementen behielten die beiden Elemente MIME_INFO und USER_DEFINED_EXTENSIONS ihren Namen bei. Die restlichen sechs Elementnamen wurden angepasst.

Die mittlere Tabellenspalte zeigt die Kindelemente des ARTICLE-Elements, wie sie laut XML-Schema-Datei in BMEcat-2005 einzusetzen sind (die BMEcat-2005-Spezifikation selbst macht dazu keine Angaben). Zur Glättung des Versionssprungs von 1.2 auf 2005 werden von den fünf in Version 2005 neuen Elementen drei ergänzt: SUPPLIER_IDREF, ARTICLE_CONTACTS und ARTICLE_LOGISTIC_DETAILS. Von diesen drei ergänzten Elementen werden zwei Elemente zurück umbenannt auf die Bezeichnungsweisen von BMEcat-1.2, nämlich PRODUCTS_CONTACTS nach ARTICLE_CONTACTS und PRODUCT_LOGISTIC_DETAILS nach ARTICLE_LOGISTIC_DETAILS.

Bei den Kindelementen des Elementes PRODUCT_REFERENCE beziehungsweise ARTICLE_REFERENCE ist die Interpretation der Spezifikation weniger klar:

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 2: Inhalte der Artikel-Referenzen bei den BMEcat-Versionen

Das Auffüllen des alten Elements ARTICLE_REFERENCE mit den neuen Kindelementen SUPPLIER_IDREF, REFERENCE_DESCR und MIME_INFO ist vergleichbar mit dem Vorgehen bei dem Element ARTICLE im vorhergehenden Beispiel.

Wie verhält es sich jedoch mit dem Kindelement ART_ID_TO unter dem ARTICLE_REFERENCE-Element? Die BMEcat-2005-Spezifikation spricht von der Ablösung und Ersetzung des Elements ART_ID_TO durch PROD_ID_TO[66]. Die Formulierung könnte so verstanden werden, dass sie in Übereinstimmung mit der Definition der XML-Schema-Datei steht. Allerdings ist auch eine andere Interpretation denkbar, die der XML-Schema-Datei widerspricht.

Schwieriger wird die Beurteilung, wenn ein Kindelement in der BMEcat-Version 2005 ergänzt wird, aber auch gleich weiter in einen anderen Elementnamen umbenannt wird. Als Beispiel dient in diesem Fall das Element PRODUCT_FEATURES beziehungsweise ARTICLE_FEATURES mit dessen Kindelementen:

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 3: Inhalte der Produktmerkmale bei den BMEcat-Versionen

In diesem Fall stimmen vier der sechs Kindelemente überein. Das Kindelement REFERENCE_FEATURE_GROUP_ID2 wurde für Version 2005 auch unter dem alten Element ARTICLE_FEATURES erweitert; unter Version 1.2 von BMEcat gab es das Kindelement noch nicht. Insoweit gibt es noch keinen grundlegenden Unterschied zu den vorherigen Beispielen.

Das verbleibende Kindelement CLASSIFICATION_GROUP_ARTICLEORDER folgt in der Namensgebung nicht dem bisherigen Schema. Dazu hätte der Elementname GROUP_PRODUCT_ORDER unverändert unter dem Element ARTICLE_FEATURES eingefügt werden müssen. Das ist jedoch nicht der Fall. Der Name des Kindelementes ergibt sich auch nicht durch Rückumbenennung von GROUP_PRODUCT_ORDER in GROUP_ARTICLE_ORDER. Stattdessen wird in BMEcat-2005 unter dem Element ARTICLE_FEATURES das Kindelement mit dem Namen CLASSIFICATION_GROUP_ARTICLEORDER eingesetzt. Die Diskrepanz erhellt sich erst, wenn bekannt ist, dass Version 2005 von BMEcat ursprünglich ein Kindelement namens CLASSIFICATION_GROUP_PRODUCTORDER vorgesehen war, das Kindelement in der finalen Ausgabe der Spezifikation jedoch noch umbenannt wurde in GROUP_PRODUCT_ORDER.

In einigen extremen Fällen kann es sogar zum Einsatz von alten und neuen Namenskonventionen im selben Dokumenten-Teilbaum kommen.

Zum Beispiel gibt es in BMEcat-2005 unter dem ARTICLE-Element ein SUPPLIER_AID-Kindelement. Wenn jedoch unter ARTICLE ein Kindelement ARTICLE_ORDER_DETAILS ausgewählt wird, und darunter PACKING_UNIT-Elemente so befindet sich darin ein SUPPLIER_PID-Kindelement.

In einem dieser Vermischungsfälle liegt allerdings ein Fehler der XML-Schema-Datei von BMEcat-2005 nahe: In der XML-Schema-Datei ist zwar ein Element ARTICLE_DIMENSIONS definiert, allerdings gelangt es nie zum Einsatz. Stattdessen wird unter dem Element ARTICLE_LOGISTIC_DETAILS ein Kindelement PRODUCT_DIMENSIONS gelistet. Vermutlich sollte an dieser Stelle das Element ARTICLE_DIMENSIONS stehen.

3.3 Grundlegende Konzepte

3.3.1 Muss- und Kann-Bestandteile

Die BMEcat-2005-Spezifikation widmet der Beschreibung von Muss-Feldern und Kann-Feldern ein eigenes Kapitel[70]. Der Einsatz von Muss- und Kann-Feldern ist grundlegend für BMEcat-Dokumente; daher werden sie näher betrachtet.

3.3.1.1 Die Begriffe Element, Attribut und Feld

Im Umkreis von XML haben die Begriffe Element und Attribut klar umrissene Bedeutungen[71]. Zentraler Bestandteil eines XML-Dokuments sind Elemente. Elemente können insbesondere Zeichenketten oder Unterelemente enthalten. Beginnend mit einem Wurzel-Element entsteht so eine hierarchisch strukturierte Ansammlung von Elementen. Ein Element enthält optional Attribute - also Eigenschaften, die das Element näher kennzeichnen; Attribute sind daher nicht mit Elementen gleichzusetzen.

Hingegen ist der Begriff des Feld es im Zusammenhang mit XML erklärungsbedürftig. Die Spezifikation von BMEcat-2005 trifft folgende Aussage[72]:

Muss-Felder sind XML-Elemente [...]. Kann-Felder sind XML-Elemente[...].

Nach dieser Aussage handelt es sich bei Feldern also um Elemente. Attribute sind nach dieser Aussage jedoch keine Felder! Wenn von Muss-Feldern und Kann-Feldern die Rede ist, dürften also nur Elemente gemeint sein, keine Attribute.

Die Klärung der Subsumierung von Attributen als Felder besitzt durchaus weitergehende Relevanz: Bei Feldern verlangt die BMEcat-2005-Spezifikation die Einhaltung einer festgelegten Reihenfolge. Bei Nicht-Feldern gegenüber schreibt BMEcat-2005 die Reihenfolge nicht vor[73].

Im Verlauf der BMEcat-2005-Spezifikation sind auch Attribute als Muss-Attribute oder Kann-Attribute gekennzeichnet[74]. Weiterhin gibt es in den tabellarischen Attribut-Beschreibungen der Spezifikation eine Spalte namens Feldlänge. Diese Indizien deuten daraufhin, dass die Bezeichnung Feld in der Spezifikation tatsächlich Elemente als auch Attribute umfassen soll.

3.3.1.2 Definition von Muss- und Kann-Feldern

Zur Verwendung von Muss- und Kann-Feldern legt die BMEcat-2005-Spezifikation fest[75]:

Das BMEcat®-Format unterscheidet Muss- und Kann-Felder. Muss-Felder sind XML-Elemente, die in einer BMEcat®-konformen XML-Datei innerhalb des umschließenden Kontextes auftreten müssen. Kann-Felder sind XML-Elemente, die in einer BMEcat®-konformen XML-Datei innerhalb ihres Kontextes auftreten können.

Leider hält sich die BMEcat-2005-Spezifikation nicht durchgehend an die eigene Vorgabe. Dazu ein Beispiel, das unverändert der Spezifikation entnommen wurde[76]:

Abbildung in dieser Leseprobe nicht enthalten

Das Beispiel widerspricht der Spezifikationsvorgabe, nach der unmittelbar vor dem CONTACT_NAME-Element ein CONTACT_ID-Element auftauchen muss[77]. Das CONTACT_ID-Feld fehlt jedoch in dem Beispiel.

3.3.1.3 Muss- und Kann-Sequenzen

Die Unterelemente eines Elements werden in der Regel in Form einer Sequenz angegeben. Eine Sequenz gibt eine festgelegte Elementreihenfolge vor[78]. Die Sequenz als Ganzes ist als Muss- oder Kann-Sequenz qualifiziert[79].

Nicht ausdrücklich geregelt sind in der Spezifikation Spezialfälle der Sequenzen:

Wie ist eine Konstellation zu interpretieren, bei dem eine Muss-Sequenz angegeben ist, die wiederum nur Kann-Elemente enthält? Angenommen, keines der Kann-Elemente der Sequenz tritt auf. Jedes Element für sich genommen kommt dann mit Häufigkeit 0 vor, und entspricht damit der Vorgabe für das Element selbst. Ist andererseits damit die Vorgabe für die Muss-Sequenz erfüllt? Falls ja, könnte in diesem Fall die Muss-Sequenz durch eine Kann-Sequenz ohne Änderung der Bedeutung ausgetauscht werden.

Die Konstellation mit einer Muss-Sequenz aus Kann-Elementen kommt etliche Male in der BMEcat-2005-Spezifikation vor. In einem der Vorkommen - nämlich zum Element PARTY - gibt es ein Indiz, das die Bewertung dieser Konstellation erlaubt[80]:

[...]


[1] siehe /XML/

[2] siehe /fmpn/

[3] siehe /Spez2005/

[4] siehe /Spez2005-CLASS/

[5] siehe /Spez2005-FORM/

[6] siehe /Spez2005-CONF/

[7] siehe /Spez2005-IPP/

[8] siehe /Spez2005-Schema/

[9] siehe auch /Validierung/

[10] siehe auch /Verifizierung/

[11] Ein Dokument, das geringfügig von den Anforderungen der BMEcat-2005-Spezifikation abweicht, könnte als „BMEcat-2005-Derivat“ bezeichnet werden

[12] siehe das Kapitel 1.6 für Details

[13] siehe /Spez2005-Schema/

[14] Weitere Beispiele für Widersprüche zwischen der BMEcat-2005-Spezifikation und der beigefügten XML-Schema-Datei werden im Verlauf des Buches noch erwähnt.

[15] siehe /Spez2005/, Seite 196, sowie /Spez2005-Schema/

[16] siehe /Spez1.2/, Seite 100, sowie /Spez1.2-Schema/

[17] ebd.

[18] siehe /Spez2005/

[19] siehe Kapitel 1.6

[20] siehe /Spez2005/, Seite 138

[21] siehe /Spez2005/, Seite 8

[22] Es spricht nichts dagegen, den Produkt-Begriff weit zu fassen. Insbesondere können auch Dienstleistungen als besondere Art eines Produkts aufgefasst werden.

[23] Die Begriffe "Produkt" und "Artikel" werden in der Folge synonym verwendet.

[24] siehe /BMEorg/, /BME/ sowie /BMEcat/

[25] siehe /Berlecon/

[26] siehe /Spez1.01/

[27] siehe /Spez1.2/

[28] siehe /Spez2005/

[29] siehe /eCl@ss/

[30] siehe /BMEadv/

[31] siehe /eclassWiki/

[32] siehe /eclassEmbed/ und /eclassVer/

[33] siehe /XML/

[34] siehe /Datanorm/

[35] siehe /SemWeb/, auch /Schema/

[36] siehe /XMLDekl/

[37] siehe /UTF-8/

[38] siehe /Entity/

[39] siehe /Spez2005/, Seite 11

[40] siehe /Spez2005/, Seite 59

[41] siehe /Spez2005/, Seiten 60 und 62

[42] siehe /Spez2005/, Seite 70

[43] siehe /Spez2005/, Seiten 66 und 67; das gleiche Prinzip wird im Falle von E-Mails an einigen weiteren Stellen der Spezifikation angewandt.

[44] siehe /Spez2005/, Seite 67

[45] siehe /Spez2005/, Seite 57

[46] siehe /Spez2005/, Seite 59

[47] siehe /Spez2005/, Seite 61

[48] siehe /Spez2005/, Seite 17

[49] siehe /Spez2005/, Seite 31

[50] Hinweis: Die Stichprobe der Internet-Recherche des Autors wies gerade diesen Fehler relativ häufig auf (siehe Kapitel 1.1).

[51] siehe /Spez2005/, Seite 106f

[52] siehe /Spez1.2/, Seite 155

[53] siehe /Spez2005-CLASS/, Seite 82

[54] siehe /Spez2005/, Seite 17f

[55] siehe /Spez2005/, Seite 18

[56] Die ältere Bezeichnung "EAN" wurde inzwischen abgelöst durch "GTIN".

[57] Um ein gültiges Dokument zu erhalten, sind die XML-Kommentare noch geeignet zu ergänzen

[58] siehe /Spez2005/, Seite 18

[59] sieh Kap. 1.7.3

[60] siehe /Spez2005/, Seite 111

[61] siehe /Spez2005-Schema/, Definition des Elements ARTICLE in der Datei bmecat_2005.xsd

[62] siehe /Spez1.2/, Seite 57

[63] siehe /Spez2005/, Seite 204

[64] siehe /Spez2005-Schema/, Definition des Elements ARTICLE_REFERENCE in der Datei bmecat_2005.xsd

[65] siehe /Spez1.2/, Seite 110

[66] siehe /Spez2005/, Seite 204

[67] siehe /Spez2005/, Seite 138

[68] siehe /Spez2005-Schema/, Definition des Elements ARTICLE_FEATURES in der Datei bmecat_2005.xsd

[69] siehe /Spez1.2/, Seite 75

[70] siehe /Spez2005/, Seite 11

[71] siehe zum Beispiel /XML/

[72] siehe /Spez2005/, Seite 11

[73] siehe Kap. 3.1.5

[74] siehe /Spez2005/, Seite 9

[75] siehe /Spez2005/, Seite 11

[76] siehe /Spez2005/, Seite 59

[77] siehe /Spez2005/, Seite 60f

[78] siehe /Spez2005/, Seite 10

[79] in vergleichbarer Weise geschieht die Qualifizierung auch bei einer Auswahl

[80] siehe /Spez2005/, Seite 93

Ende der Leseprobe aus 157 Seiten

Details

Titel
Eigenschaften und Besonderheiten des Katalogdaten-Austauschformates BMEcat 2005
Autor
Jahr
2017
Seiten
157
Katalognummer
V384274
ISBN (eBook)
9783668597822
ISBN (Buch)
9783668597839
Dateigröße
1097 KB
Sprache
Deutsch
Schlagworte
bmecat, produktkatalog, pim, produktdatenmanagement, e-business, xml, datenaustausch, katalog
Arbeit zitieren
Dipl. Inf., Dipl. Wirt.inf. Franz Mühlbauer (Autor), 2017, Eigenschaften und Besonderheiten des Katalogdaten-Austauschformates BMEcat 2005, München, GRIN Verlag, https://www.grin.com/document/384274

Kommentare

  • Noch keine Kommentare.
Im eBook lesen
Titel: Eigenschaften und Besonderheiten des Katalogdaten-Austauschformates BMEcat 2005


Ihre Arbeit hochladen

Ihre Hausarbeit / Abschlussarbeit:

- Publikation als eBook und Buch
- Hohes Honorar auf die Verkäufe
- Für Sie komplett kostenlos – mit ISBN
- Es dauert nur 5 Minuten
- Jede Arbeit findet Leser

Kostenlos Autor werden