The role of process-controlled components in ebXML messages

1. The role of process-controlled components in ebXML messages Martin Bryan CEN/ISSS Electronic Commerce Workshop working group on Defining and Managing Semantics and Datatypes (DAMSAD)

2. Structure of Presentation • What is the problem we need to solve? • XML DTDs/Schemas • Data Dictionaries • Related standards initiatives • Why is context important to solving this problem? • How does ebXML use context?

3. The Problem - Overview • DTDs define semantics for a sequence of elements that make up a message • DTDs that cover wide ranges of data tend to become very complicated (or non-specific) and difficult to manage • Data dictionaries provide a "flat view" of all data within a company • Data is presumed to be used consistently in all situations

4. The Problem - DTDs • DTDs that allow everything and, therefore, control nothing <!ELEMENT shared-datatype(a?, b*, c?, d*, e?, f*)> <!ELEMENT a (x|y|z)*> • Parameterized DTDs that allow complete user control <!ELEMENT shared-datatype (%p.x;)*> <!ENTITY % p.x "a|b|c%x.extensions;"> <!ENTITY % x.extensions "">

5. Do XML Schema Types help? <complexType name="AbstractAddress" abstract="true"> <sequence><element name="name" type="string"/><element name="street" type="string"/><element name="city" type="string"/> </sequence></complexType><complexType name="US-Address"> <complexContent> <extension base="AbstractAddress"> <element name="state" type="US-State"/><element name="zip" type="positiveInteger"/> </extension> </complexContent></complexType>

6. Creating Abstract Elements <element name="AbstractOrder" abstract="true"> <sequence> <element name="Partner"substitutionGroup="AbstractAddress"> <minOccurs value="2"> <maxOccurs value="10"> </element><element name="Items" substitutionGroup="AbstractItems"> <minOccurs value="1"> <maxOccurs value="unbounded"> <element/> </sequence> <attribute name="orderDate" type="date"/></element>

7. Using Abstract Elements <element name="PurchaseOrder"><annotation> <documentation>Local Purchase Order</documentation></annotation><complexType> <complexContent> <extension base="AbstractOrder"/></complexContent></complexType> </element>

8. The Problem - Data Dictionaries • Too little control - generic data types • Name - without a context it is meaningless • Too much control - constrained data types • AcknowledgementRecipientName - can't be used in another context without renaming • Confusing data type with data role (à la ISO Basic Semantic Register) • AcknowledgementRecipient.Name - name is not a data type, it’s a use of a data type

9. Mapping ISO 11179 view to XML Concept/Class Element Name Attribute Name/Embedded Element Properties Attribute Value/Element Content Representation Meaning Interpretation of Value

10. UN/EDIFACT message structures • EDIFACT = Electronic Data Interchange for Administration, Commerce and Transport • EDIFACT messages are made up of reusable "segments" • Segments have a fixed sequence of "data elements" • Role of segments indicated by "qualifier" data elements

11. Example of EDIFACT message UNH+900576+ORDERS:D:93A:UN:EAN007' BGM+220+H940568' DTM+137:19940201:102' NAD+BY+5412345000176::9' NAD+SU+4012345000094::9' LIN+1' PIA+5_1857990455:IB' IMD+F+BAU+:::Farell J G' IMD+F+BTI+:::The Singapore Trip' QTY+21:1' PRI+XXX:7.99' UNS+S' CNT+2:2' UNT+15+900576'

12. Process Chains/Hierarchies Process Chains Manufacture Distribute Retail Order Response Despatch Receipt Invoice Payment Transport Booking Collection Notification Delivery Notification Subprocesses Container Movement Container Arrival

13. How context affects information • Some examples Order/Item/Quantity[Units="Kilogram"] Despatch/Item/Quantity[Units="Kilogram"] Receipt/Item/Quantity/Received[Units="Kilogram"] Invoice/Item/Quantity[Units="Kilogram"] • Note how the initial context changes • Note how the qualifier can change place • Need to be able to identify whenever a particular type of units applies to a quantity

14. Basic processes for an Order* • How is it to be distinguished? • When was it issued? • Who issued it? • Who is to be executed by? • Who else is to be informed? • What is to be supplied? • When and where is it to be delivered? * Expressed as a set of questions that need to be answered in order to create an order

15. Basic processes for Order Response • How is it to be distinguished? • When was it issued? • Who issued it? • What order does it refer to?  • Who is to be executed by? • Who else is to be informed? • What is to be supplied? • When and where is it to be delivered?

16. Basic processes for Despatch Note • How is it to be distinguished? • When was it issued? • Who issued it? • What order does it refer to? • Who is to be executed by?  • Who else is to be informed? • What is to be supplied? • When and where is it to be delivered?

17. Basic processes for Receipt • How is it to be distinguished? • When was it issued? • Who issued it? • What order does it refer to? • Who delivered the goods?  • When and where were they delivered? • What was received and accepted?  • What was rejected/not received? 

18. Basic processes for Invoices • How is it to be distinguished? • When was it issued? • Who issued it? • Who is it submitted to?  • What order does it refer to? • What did the goods delivered cost?  • What tax needs to be paid on the goods?  • What is the total payment?  • Where is payment to be made? 

19. Basic processes for Payment Instructions • How is it to be distinguished? • When was it issued? • Who issued it? • Who is to receive the payment?  • Who else needs to be informed?  • What invoice does it refer to?  • What did the goods delivered cost? • What tax has been paid on the goods? • What is the total payment?

20. Conclusions from above • Business messages are designed to provide a set of answers to an agreed set of questions • The order in which the questions are answered is not relevant • Failure to answer one of the questions may invalidate the whole message • Not all parts of all questions need to be answered for a particular message

21. Conclusions from conclusions - 1 • Need to design reusable questions • Answers may be omitted where not relevant • Need to be able to obtain answers from different sources • Often able to supply some answers from previously answered questions • Some questions need input from human or "intelligent" system (i.e. bar code readers)

22. Conclusions from conclusions - 2 • The process and subprocesses in which information is collected provide a "parent" for the answer <Deliver> <Born><Date> <Date><Time> <Time><Address> <Address> <BuildingID> <Place> <Street> <Region> <Place> <Country> <PostalID> <Region> <Country>

23. Conclusions from conclusions - 3 • Questions make natural parents <DeliverySpecification><WhenRequired> <Date><Time> <WhereRequired> <Address><BuildingID><Street><Place><PostalID> <Region> <Country> <WhatIsRequired> <ProductIdentification> <QuantityRequired>

24. ebXML • Brings together XML and EDI experts • OASIS members for XML • UN/EDIFACT for EDI • Many other trade bodies for vertical industries • Looking to identify sharable processes • Core components for data • Common business processes

25. The ebXML committee structure • Requirements • Technical Architecture • Business Process/Core Components • Registry/Repository • Transport • Marketing

26. Requirements Technical Architecture Process Chain Business Process Transport Business Document Components Processes Info.Entity Methods Info.Entity Info.Entity Registry and Repository ebXML Group Linkages

27. Overall ebXML BP Metamodel

28. Message metamodel Document Model Taxonomy Functional Set Core Component Type Definition Assemble Types Context Rules Basic Information Entity Aggregate Information Entity Application Rules Application Component Aggregation Rules Type Use Rules Datatype Embedded Group Type Constraint Type Extension External List Permitted Value Datatype Constraint Core Components Context Constraints Permitted ValueMeaning

29. ebXML Core Component Types • Core Component Type Definitions • Basic Information Entity • Data Type • Permitted Values/External Lists • Permitted Value Meanings • Aggregate Information Entity • Embedded Group • Aggregation Rules • Type Use Rules • Type Constraint

30. Context Control • Identify and assemble type definitions • Identify subcomponents to be used • Identify relevant context taxonomies • Assign application dependent names • Apply context specific rules • Identify relevant context taxonomies • Define tests to be used to select rule • Define extensions and restrictions to be applied

31. Assemble Types <Assemble Name=”PurchaseOrder”><CreateGroup Type=”sequence”> <CreateElement Type=”PartyType” id="Buyer"><Name>Buyer</Name> <CreateGroup type="sequence"> <UseElement name="Name"/> <UseElement name="Address"> <UseElement name="StreetName"/> <UseElement name="City"/> <UseElement name="State"/> <UseElement name="ZIP"/></UseElement> </CreateGroup> <Condition test="Region='UK'"> <Rename from=”address” to=”addressUK”/><Rename from="address/State" to="County"/><Rename from="address/ZIP" to="PostalCode"/> </Condition></CreateGroup> </Assemble>

32. Condition Rules <Rule><Taxonomy context="Process" ref="http://www.ebxml.org/classes/CoreBP"/><Taxonomy context="Industry" ref="http://www.ebxml.org/classes/industry/aviation"/> <Condition Test="Process = 'Quote'"> <Condition Test="Industry = 'Automotive'"> <Action ApplyTo="QualifyingInfo"> <Add> <Field Name=”DrivingRecord” Type=”DrivingRecord”/> <Field Name=”CarDescription” Type=”CarDescription”/> <Field Name=”DrivingHabits” Type=”DrivingHabits”/> </Add><Rename from="@Convictions" to="@DrivingConvictions"/></Action></Condition> . . . </Rule>

33. ebXML Registry Structure

34. What have we learnt? • Information is dependent on context • You need to know the context of a message to be able to interpret its contents • Context is dependent on the processes involved • Therefore semantic definitions must also be dependent of processes using data elements

35. Where to find more information • On ebXML • www.ebxml.org • On European Electronic Commerce • www.cenorm.be/isss/Workshop/ec • On standards for Electronic Commerce • www.diffuse.org/standards.html • On background philosophies • www.sgml.u-net.com