Metadata for Electronic Commerce

Tom Worthington FACS HLM

Visiting Fellow, Department of Computer Science, Australian National University, Canberra

For: COMP3410: Information Technology in Electronic Commerce, at The Australian National University

This document is Version 2.0 12 August 2003: http://www.tomw.net.au/2003/dm/mcommerce.html

Introduction
Differences Between Metadata for DBMS and E-commerce
UN/EDIFACT
Example of XML/EDI: Payment Order
XML E-commerce Standards
Further Information

Introduction

This material is part of Metadata and Electronic Document Management: Searching for a Common Understanding, prepared for “Information Technology in Electronic Commerce” (COMP3410), at the Australian National University, semester 2, 2003.

Differences Between Metadata for DBMS and E-commerce

Metadata for managing documents (as discussed in the previous section) tends to have a few dozen elements for each document. Most elements are text fields, rather than numeric values or qualified values. Metadata for electronic commerce uses more elements, more qualified and numeric values.

UN/EDIFACT

25. At a meeting in 1990, a UN working party agreed on the following definition of UN/EDIFACT:

26. United Nations rules for Electronic Data Interchange For Administration, Commerce and Transport. They comprise a set of internationally agreed standards, directories and guidelines for the electronic interchange of structured data, and in particular that related to trade in goods and services between independent, computerized information systems.

27. Recommended within the framework of the United Nations, the rules are approved and published by UN/ECE in the (this) United Nations Trade Data Interchange Directory (UNTDID) and are maintained under agreed procedures. (UNECE 19xx)

EDIFACT is one of the two internationally cited family of standards for Electronic Data Interchange (EDI). The other standard is the USA's ANS X12 Syntax. In most cases the same metadata elements can be used with EDIFACT and ANS X12:

This code list is used by United States Government contracting and grant activities to indicate the data expressions that are contained herein. It is designed principally for use with Electronic Date Interchange (EDI) in either the American National Standard X12 syntax or the United Nations/Electronic Data Interchange for Administration, Commerce, and Transport (UN/EDIFACT) syntax. It may be used in other data systems as appropriate, to include as domain values for standard data schemes or as application data...

BTA
Small Disadvantaged Business Performing in the US
BTB	Other Small Business Performing in the US
BTC	Large Business Performing in the US
BTD	Javits-Wagner-O'Day Act (JWOD) Participating Nonprofit Agencies
BTF	Hospital
BTL	Foreign Concern/Entity
BTM	Domestic Firm Performing Outside US
BTU	Historically Black Colleges and Universities or Minority Institutions
BTV	Other Educational
BTZ	Other Nonprofit

From: Federal Procurement Code List One (FP1), National Institute of Standards and Technology, 1998 URL: http://snad.ncsl.nist.gov/dartg/edi/fededi-coding.html

Standards exist for electronic versions of commonly used business forms, such as invoices and Remittance Advice:

810 Invoice - Updated in January 1996 and published as NIST Special Pub 881-10 - ( ASCII, RTF, or PDF ) - Version Control Number: 003040FED01A regenerated as 003040F810_0.
820A Payment Order/Remittance Advice (Automated Standard Application for Payments): Version Control Number 003040F820A1 - updated April 20, 1999 - ( PDF, ASCII, RTF

From: Federal Procurement Code List One (FP1), National Institute of Standards and Technology, 1999 URL: http://snad.ncsl.nist.gov/dartg/edi/3040-ic.html

Example of XML/EDI: Payment Order

The Interim Report for CEN/ISSS XML/EDI Pilot Project give the example of an XML version of an EDIFACT National Payment Order:

<?xml version="1.0"?>
<!DOCTYPE PAY-NAT SYSTEM "pay-nat.dtd">
<PAY-NAT RefNo="0005">
<BGM>AA124</BGM>
<DTM1>19980812</DTM1>
<DTM1 Type="203">19970815</DTM1>
<MOA>100</MOA>
<FII Party="OR">
<UKB>010344</UKB>
<ACC>23412345</ACC>
<ACN>MR N SMITH</ACN>
</FII>
<FII Party="BF">
<UKB>010344</UKB>
<ACC>01341234</ACC>
<ACN>MR N WHITE</ACN>
</FII>
<NAD Of="OY" EAN="5012345678900"/>
<PRC>
<DOC& Type="380"gt;AA123</DOC>
</PRC>
</PAY-NAT>

From: The Interim Report for CEN/ISSS XML/EDI Pilot Project, CEN/ISSS XML/EDI WORKSHOP, 2000, URL: http://www.cenorm.be/isss/workshop/ec/xmledi/documents_99/xml001_99.htm#NatPay Archived at: http://www.cenorm.be/isss/workshop/ec/xmledi/documents_99/xml001_99.htm#NatPay

The elements used are:

PAY-NAT: Container for the message segments required for a national payment instruction.
Note: A national payment instruction does not normally involve currency exchange.
May optionally have a RefNo attribute that identifies the sequence of the message within a larger interchange.
BGM: Identifies the beginning of the message.
Contents of the element are used as the reference number for the message.
DTM1: Date of message, in ISO 8601 format.
If a time is to be specified as a qualifier to the date the optional Format attribute must be assigned a value of 203 in place of its default value of 102. If a period, rather than a single date, is to be specified the Format attribute must be assigned a value of 718.
The first occurrence of this element must specify the date of issue of the payment instruction.
DTM2: Date of payment, in ISO 8601 format.
The optional Type attribute can be assigned one of the following values:

140 Payment due date
203 Execution date/time, requested

If no value is specified the value of 140 will be assigned.
If a time is to be specified as a qualifier to the date the optional Format attribute must be assigned a value of 203 in place of its default value of 102. If a period, rather than a single date, is to be specified the Format attribute must be assigned a value of 718.
The first occurrence of this element must specify the date of issue of the payment instruction.
MOA: Monetary amount of payment.
Defaults to GBP - Pounds sterling - for ANA. (See also restrictions imposed by INS element.)
The optional Currency attribute can alternatively be used to record the ISO 4217 code for the currency the amount is specified in (e.g. EUR to indicate an amount in Euros).
FII: Container for financial institution information.
When details of a bank other than that of the beneficiary are being provided the optional Party attribute should be assigned a value of OR (Ordered bank).
UKB: Compulsory UK bank branch sort code of institution.
Note: The fixed values for the attributes associated with this element require that the value be entered according to the rules laid down for the UK by the Association of Payment Clearing Services.
ACC: Compulsory account number.
ACN: Optional account holder name.
NAD: Name and address of any non-financial institutions (the buyer and the seller of the good for which payment is being made) associated with payment order.
The role played by the identified organization must be indicated by the use of one of the following values for the Of attribute:

OY Ordering customer
BE Beneficiary

The unique EAN assigned to the relevant party must be entered as the value of the EAN attribute.
Optionally name and address details can be added as a set of <NAD-LINE> elements within the address element to assist printing of the document.
PRC: Optional container for details of documents that are associated with the process.
DOC: Reference document against which payment is being made.
The compulsory Type attribute from the following list:

380 Invoice
381 Credit note
383 Debit note
387 Hire invoice
389 Self-billed invoice
394 Lease invoice
481 Remittance advice
493 Statement of account message

Contents of the element are used as the reference number for the document being referenced.

The XML document type definition defining of this message is:

<!-- SIMPL-EDI Message Type for National Payment Orders -->
<!-- XML Document Type Definition created by The SGML Centre
     Last Updated: October 1998
     -->
<!-- Note: Element names in this version of the DTD are constrained
           to be non-significant (i.e. have no integral semantic meaning).
           Element names are, therefore, based on the alphanumeric
           identifiers assigned to the equivalent information in the
           EDIFACT messages defined in the SIMPL-EDI report dated
           12th May 1998.
     -->
<!-- Note: Attributes with FIXED values should not be used in messages.
           Such attributes are provided in the DTD simply to record the
           mapping between XML and EDIFACT versions of SIMPL-EDI orders.
     -->

<!ELEMENT PAY-NAT      (BGM, DTM1, DTM2, MOA, FII*, NAD*, PRC?) >
<!ATTLIST PAY-NAT
          UN-EDIFACT:Prefix    CDATA   #FIXED                "UNH"
          RefNo                CDATA                         #IMPLIED
          MessageTypeID        CDATA   #FIXED                "PAYEXT"
          Version              CDATA   #FIXED                "D"
          ReleaseNumber        CDATA   #FIXED                "96A"
          Agency               CDATA   #FIXED                "UN"
          AssociationCode      CDATA   #FIXED                "SIMP01"   >

<!ELEMENT BGM        (#PCDATA) >
<!ATTLIST BGM
          UN-EDIFACT:Prefix    CDATA   #FIXED                "BGM"
          Type                 CDATA   #FIXED                "451"
          Agency               CDATA   #FIXED                "136"      >

<!ELEMENT DTM1       (#PCDATA) >
<!ATTLIST DTM1
          UN-EDIFACT:Prefix    CDATA   #FIXED               "DTM"
          Type                 CDATA   #FIXED               "137"
          Format               (102|203|718)                "102"
          MaxOccurs            CDATA   #FIXED               "10"       >

<!ELEMENT DTM2       (#PCDATA) >
<!ATTLIST DTM2
          UN-EDIFACT:Prefix    CDATA   #FIXED               "DTM"
          Type                 (140|203)                    "140"
          Format               (102|203|718)                "102"
          MaxOccurs            CDATA   #FIXED               "10"       >

<!ELEMENT MOA       (#PCDATA) >
<!ATTLIST MOA
          UN-EDIFACT:Prefix    CDATA   #FIXED       "MOA"
          Type                 CDATA   #FIXED       "9"
          Currency             CDATA                "GBP"                 >

<!ELEMENT FII       (UKB, ACC, ACN?) >
<!ATTLIST FII
          UN-EDIFACT:Prefix    CDATA   #FIXED             "FII"
          Party                (BF|OR)                    "BF"
          MaxOccurs            CDATA   #FIXED             "4"             >

<!ELEMENT UKB       (#PCDATA) >
<!ATTLIST UKB
          List                 CDATA   #FIXED             "154"
          Agency               CDATA   #FIXED             "133"           >

<!ELEMENT ACC       (#PCDATA) >

<!ELEMENT ACN       (#PCDATA) >

<!ELEMENT NAD       (NAD-LINE*) >
<!ATTLIST NAD
          UN-EDIFACT:Prefix    CDATA   #FIXED             "NAD"
          Of                   (OY|BE)                    #REQUIRED
          EAN                  CDATA                      #REQUIRED
          Agency               CDATA   #FIXED             "9"
          MaxOccurs            CDATA   #FIXED             "6"             >
<!-- Note: The EAN has been treated as a required attribute, rather than
            data, because it is presumed that a list of valid entries will
            be presented to the user by each system.
     -->

<!ELEMENT NAD-LINE  (#PCDATA) >

<!ELEMENT PRC       (DOC+) >
<!ATTLIST PRC
          UN-EDIFACT:Prefix    CDATA   #FIXED             "PRC"
          Type                 CDATA   #FIXED             "8"             >

<!ELEMENT DOC       (#PCDATA) >
<!ATTLIST DOC
          UN-EDIFACT:Prefix    CDATA   #FIXED             "DOC"
          Type                 (380|383|381|387|
                                389|394|481|493)          #REQUIRED
          MaxOccurs            CDATA   #FIXED             "9999"          >

This is a reasonably readable example. However, there is a bewildering array of such proposed standards. Also commercial vendors of electronic document and e-commerce products use variations of standards, draft proposed standards, or attempt to create defacto standards based on market dominance.

XML E-commerce Standards

W3C provide a very useful table to compare XML protocols . As with all good standards development, W3C has been taking technologies developed by industry and turning them into standards. W3C started at the bottom end, developing technical document standards and has more recently working its way up into data definitions, structure, transaction formats and discovery services.
The XML e-commerce standards are relatively new. There tends to be a heavy overlap of the companies involved. SOAP was developed by a consortium of Ariba, Inc., Commerce One, Inc., Compaq, HP, IBM, Microsoft, SAP and other major companies and is now being standardised by W3C. BizTalk was developed by Microsoft. WSDL was developed by Ariba, IBM and Microsoft. Beyond W3C's technical brief there are other standards which describe specific commercial transactions, such as EbXML from UN/CEFACT oasis.

Making th situation more confusing is the overlap between business domains and technical standards. Early work mixed up the development of what sort of business information could be described (for example a payment advice note) and the format in which the information was encoded (such as in XML). Also many of the standards document are difficult to find, being stored in large PDF documents or at web addresses which change (where is the document defining Microsoft's BiZTalk).

The W3C standards publication process has greatly improved this situation by providing well formatted web documents which are easily found at fixed URLs and by avoiding addressing the business domain. It is easy to find a W3C standard using a web search, to copy a section out of it and paste it (complete with formatting) into a document and to cite the URL of the standard with a reasonable expectation it will still be there when someone goes looking for it. What is needed is for those proposing business standards to follow W3C's lead, by providing documents addressing the business domain and which can be used easily.

Database Related Standards
Web Services Description Language (WSDL) Version 1.2		W3C Working Draft 9 July 2002	http://www.w3.org/TR/wsdl12	An XML language for describing Web services
Web Services Description Language (WSDL) Version 1.2	Bindings	W3C Working Draft 9 July 2002	http://www.w3.org/TR/wsdl12-bindings	Defines binding WDSL to SOAP, HTTP and MIME.
SOAP Version 1.2	Part 0: Primer	W3C Working Draft 26 June 2002	http://www.w3.org/TR/soap12-part0	SOAP Technical Primer
	Part 1: Messaging Framework	W3C Working Draft 26 June 2002	http://www.w3.org/TR/soap12-part1	A lightweight protocol for exchanging structured information in a decentralized, distributed environment.
	Part 2: Adjuncts	W3C Working Draft 26 June 2002	http://www.w3.org/TR/soap12-part2	A set of adjuncts that MAY be used with the SOAP messaging framework.
XML Schema	Part 0: Primer	W3C Recommendation, 2 May 2001	http://www.w3.org/TR/xmlschema-0/	Technical Primer
	Part 1: Structures	W3C Recommendation 2 May 2001	http://www.w3.org/TR/xmlschema-1/	Extended capabilities for describing the structure of XML 1.0 documents, beyond DTDs.
	Part 2: Datatypes	W3C Recommendation 02 May 2001	http://www.w3.org/TR/xmlschema-2/	Superset of capabilities in XML 1.0 DTDs for specifying datatypes on elements and attributes.
Document Related Standards
Extensible Stylesheet Language (XSL) Version 1.0 (aka XSL-FO)		W3C Recommendation 15 October 2001	http://www.w3.org/TR/xsl/	A language for expressing stylesheets
XSL Transformations (XSLT) Version 1.0		W3C Recommendation 16 November 1999	http://www.w3.org/TR/xslt	A language for transforming XML documents into other XML documents.
Extensible Markup Language (XML) 1.0 (Second Edition)		W3C Recommendation 6 October 2000	http://www.w3.org/TR/REC-xml	A subset of SGML designed for ease of implementation and for interoperability with both SGML and HTML.