	XML-related intellectual assets		Table of contents		Indexes		XML &, the enterprise

Legal design of XML-based standards for e-commerce

some notes on two problems in todaýs work

Lundblad, Nicklas

Nicklas Lundblad

Research Programme Coordinator

Research Corporation Media and Communication

Stockholm

Sweden

Research Corporation Media and Communication, Kista
Stockholm Sweden
Phone: +46 8 752 16 00 email: nicklas@acm.org web site: www.framkom.se

Biography

Nicklas Lundblad – Now directing the e-commerce lab at Swedish research institute FRAMKOM. Previously employed as e-commerce analyst at the Swedish Office of Science and Technology in Menlo Park, Silicon Valley. B.A. in theoretical philosophy. L.LM with work in the information technology and law area.

Abstract

This paper briefly outlines some problematic points in the design of XML-based standards for e-commerce. The source of these problems is found in the difference between EDI-based e-commerce and the more open forms of XML-based e-commerce. The Internet and the globalisation of the economy has fundamentally changed the legal situation of electronic commerce. EDI-based commerce often was the continuation of established business relations, relations in which legal issues had already been solved and handled in a satisfactory manner. In the more open forms of XML-based commerce, such as the ones we see in electronic marketsplaces, this is not always the case. On the contrary: often the parties doing business will never have encountered each other before. This changes the legal assessment of the situation and will – if unnoticed – lead to some difficult problems.

Introduction

This paper briefly deals with some complex problems pertaining to the design of XML based vocabularies and standards for e-commerce. The design of XML –based data models for business communication is a vital part of realising the dream of global electronic commerce. Legal design issues must however be confronted, and perhaps in a greater degree than is usually presumed. Otherwise the consequences can be dire for all involved.

Lingua Universalis

XML has reintroduced and rekindled the dream of alingua universalis for e-commerce, a standard definition of standard documents in business interactions and communications. This dream, however, is beset by difficulties in that these standards must be formed and agreed upon. This momentous work is now under way, but still some important issues remain to be solved. Not least of which are the legal issues this article deals with.

EDI and XML – the legal differences

One of the fundamental differences between the EDI model for e-commerce and the new XML-based initiatives is that in the new initiatives isthe interaction model.

In EDI we often see a1:1 interaction model , where companies more or less formalise an existing relationship in an electronic system, but in XML-based e-commerce some hope and expect amany:many interaction model where you, as a party to a transaction, might very well never have seen the other party in the transaction before. This necessitates a fundamental shift in the legal attitude.

In EDI the legal infrastructure was already in place – the companies had agreements and contracts, and therefore the standard did not have to incorporate these legal elements. In XML based open commerce this is not the case, and the legal elements thus need a greater amount of attention than in the EDI case.

It is important to note that other than this we today see hybrid forms of XML/EDI where the strengths of EDI are harnessed in the simplicity and low cost form of XML based solutions. See for example Kotok, Alan “Introduction to XML and EDI”, XML.com http://www.xml.com/pub/1999/08/edi/index.html (2000-03-21)

Modelling the business..

In the different vocabularies available today (such as CBL 2.0 and cXML 1.1) much effort has gone into modeling different business interactions. Building on the heritage of EDIFACT and ANSI X.12 the creators of the new vocabularies try to find universal forms of description for business communication documents such as invoices and orders.

This design is an ongoing process with focus on developing prototypes for interaction in commerce, the whole process is implementation oriented. This short passage from the cXMLspecification illustrates the thoughts of designers today:

cXML specification p 1

cXML is designed to provide a simple XML-based protocol between entities engaged in Business-to-Business eCommerce transactions over the Internet. Ease of implementation has been a primary focus along with an emphasis on prototype implementations to discover remaining issues. Most of the feedback that has been incorporated into the specification is based on ideas and solutions found during actual implementations between interacting companies and their systems.

This focus on implentation is commendable and probably shortens the time it will take for new XML-based vocabularies to become widely implemented. However, it is important that this ease of implementation does not come at the price of legal insecurity. By no fault of their own the technical designers seem to overlook the legal issues and rationalise them. This tendency will have profound implications if it is not modified in time.

...But what about the Law?

The fact that legal issues are an important part of the new reality is no secret. Technically focused design also acknowledges this fact. Often enough this acknowledgement takes the form ofan exclusion ora new definition of established legal terms. An example might illustrate the point. In the cXML specification the following MOD file is named “contract”:

<?xml version="1.0" encoding="UTF-8"?>
<!--
Copyright (c) 1996-1999 Ariba, Inc.
All rights reserved. Patents pending.

$Id: //ariba/specs/cXML/Contract.mod#11 $
-->
<!-- Imports are NOT allowed in .mod files -->

<!ELEMENT Contract (SupplierID+, Comments?, ItemSegment+)>
<!ATTLIST Contract
effectiveDate   %datetime.tz;  #REQUIRED
expirationDate  %datetime.tz;  #REQUIRED
>
<!--
Defines an item segment for the index.  An item segment is an
overlay for index items, allowing suppliers to override certain
item attributes on a per-contract basis.

Items may be segmented by some agreed-upon user-specific key that
is used to determine who is eligible for these particular overlaid
attributes (such as reduced or different prices).
Omitting the segmentKey indicates that the supplier wishes to set
the given contract price system wide (for all users).
segmentKey      - optional agreed-upon string used to segment
custom prices
-->
<!ELEMENT ItemSegment (ContractItem+)>
<!ATTLIST ItemSegment
segmentKey  %string;  #IMPLIED
>
<!--
A particular (custom) item overlay for a index item.  The item is
referenced by the supplierPartID.
ItemID - ID for the part to be overlaid.
UnitPrice - Contract price for item
Extrinsic - Named overlay. The Extrinsic should be named with the
item field name it is to overlay. The Extrinsic must contain a
<value> element which supplies the replacement value for the item
field.
For example:
<ContractItem>
<ItemId>
<SupplierPartID>123456</SupplierPartID>
</ItemId>
<Extrinsic name="URL">http://www.newaddress.com</Extrinsic>
</ContractItem>
-->
<!ELEMENT ContractItem (ItemID, UnitPrice?, Extrinsic*)>

This is clearly not even close to a contract in the legal sense of the word. It does not even contain a reference to conditions or agreements. This is – of course – not out of malice. This is rather an example of the aforementioned tendency of technically focused design to simply redefine established terms. Redefinition does not avoid the problems, though.

Legal design – some examples

To point out some particularily weak areas of legal design it is useful to give concrete examples. In this section two major issues will be addressed and the problems highlighted. In the last section some recommendations for managers will be sketched.

References to legal documents

One way of solving the problem with legal design that on the surface seems to address the problem in an optimal way is referencing an external source (this is the exclusionary model mentioned above). The typical example would be when the contractual content is located in another database, as in .

Referencing external sources

In the CBL 2.0 specification this is evident in for example the invoice format (only a small subsection is shown):

<Invoice>
 <!-- InvoiceHeader contains general information about that applies -->
 <!-- to the entire invoice -->
 <InvoiceHeader>
  <InvoiceDate>19990517</InvoiceDate> <!-- May 17th, 1999 -->

  <ContractNumber>ABC124</ContractNumber>

Here the reference is to a particular contract not anywhere present in the material. The same can be found in the orderdocument of CBL 2.0:

<OrderReference>
<!-- An account is an agreement between a buyer and a supplier, specified
by the account code. Remember that an agreement can consists of
multiple contracts. Agreement is not the same as contract.
An agreement 'contains' contract(s). -->
<AccountCode><Reference><RefNum>CTOP</RefNum></Reference> </AccountCode>

Note the hardly clarifying comment. The problem of referencing is not addressed, but instead a new definition of agreements is offered.

The design of these standards seems to be relying on an external legal safety net that might well not exist.

Referencing might seem as a good way to bypass the complex task of including and explaining legal terms in a document, but this practice of referencing external material is however deeply problematic from a legal point of view. The problem is quite complex:

How do we guarantee the integrity and authenticity of the referenced material? This is of course the main question. The referencing model stands no chance whatsoever to survive if the integrity and authenticity of the material cannot be guaranteed. Is it necessary to establish trusted third party services for authenticating and securing referenced content? If so, which parties would best serve this role?

How do we show that the parties have actually read the contract? This might seem as an absurd question, but consider the case where the referenced material has been changed from transaction A to transaction B - what are then the consequences?

Is referenced material really a part of the contract? How many references do we allow for? And what reference depth (i.e. when a document refers to a document that refers to a document...) do we allow?

The evolution of referencing practices in business to business communication seems inevitable. We can easily see that the document, as a communication metaphor, becomes less important in the new world of integrated enterprise systems. Information will be floating in many different formats and the legal system might very well have to adapt to these new practices. Doing business today, however, CEOs need to have a thorough understanding of the legal realities with which they deal. We will return to these issues in the last section, discussing actions which CEOs today need to take.

There is ongoing work and research in this area.

See for example the LegalXML consortium. http://www.legalxml.org/Information/LegalXMLWorkgroups.asp (2000-03-21)

Privacy

Another problem – admittedly one that might seem trivial on the surface– is the fact that the business communication will contain personal data. This is however not a trivial fact from the viewpoint of a legal analyst.

Personal data is subject to the conditions of theDirective 95/46/EC of the European Parliament and of the Council of 24 October 1995 on the protection of individuals with regard to the processing of personal data and on the free movement of such data.

Alla data that references individuals risks being deemed personal data. For example the following extract from a CBL 2.0 Invoice:

<InvoiceParties>
<Buyer>
<NameAddress>
<Name1>Ralph`s Automotive Parts</Name1>
<Address1>10 Main St.</Address1>
<City>Boulder Creek</City>
<StateOrProvince>California</StateOrProvince>
<PostalCode>96005</PostalCode>
<Country>US</Country>
</NameAddress>
</Buyer>
<Supplier>
<NameAddress>
<Name1>ABC Wholesale</Name1>
<Address1>1222 Industrial Park way</Address1>
<City>South San Francisco</City>
<StateOrProvince>California</StateOrProvince>
<PostalCode>96045</PostalCode>
<Country>US</Country>
</NameAddress>
</Supplier>

This part, if concerned with individuals instead of companies, could easily be deemed personal data and the processing of personal data is only allowed given certain specific conditions. If processing should occur and these conditions are not present damages can be awarded the person whose data has been processed.

Privacy problems

Often enough processing of data will be legitimate, even according to the directive, which states that:

Article 7Member States shall provide that personal data may be processed only if:(a) the data subject has unambiguously given his consent; or(b) processing is necessary for the performance of a contract to which the data subject is party or in order to take steps at the request of the data subject prior to entering into a contract; or(c) processing is necessary for compliance with a legal obligation to which the controller is subject; or(d) processing is necessary in order to protect the vital interests of the data subject; or(e) processing is necessary for the performance of a task carried out in the public interest or in the exercise of official authority vested in the controller or in a third party to whom the data are disclosed; or(f) processing is necessary for the purposes of the legitimate interests pursued by the controller or by the third party or parties to whom the data are disclosed, except where such interests are overridden by the interests for fundamental rights and freedoms of the data subject which require protection under Article 1 (1).

When the buyer is identical to the persons whose data is being processed it would seem that Article 7 (b) should be applicable. And there seems to be little doubt that this would seem to cover the majority of cases at hand.

But what of the following case in the purchase order of Commerce Onés CBL 2.0:

<Party>
<NameAddress>
<Name1>Mr. Muljadi Sulistio</Name1>
<Name2>Attention: Business Service Division</Name2>
<Address1>1600 Riviera Ave</Address1>
<Address2>Suite# 200</Address2>
<City>Walnut Creek</City>
<StateOrProvince>CA</StateOrProvince>
<PostalCode>94596</PostalCode>
<Country>US</Country>
</NameAddress>
<OrderContact>
<Contact>
<ContactName>Mr. Mike Holloway</ContactName>
<Telephone>(925) 941-3333</Telephone>
<Email>mike.holloway@commerceone.com</Email>
<Fax>(925) 941-4555</Fax>
</Contact>
</OrderContact>

Note that the order contact is not the party with which the contract is entered into, but merely a representative of that party. Does that mean that Article 7 (b) which clearly states that ” processing is necessary for the performance of a contract to which the data subject is party or in order to take steps at the request of the data subject prior to entering into a contract;” This is not the case here. The party of the contract is a company, the order contact merely a person who administers this contract. Here it would seem necessary at least to aquire the consent of all such listed people according to Article 7 (a) – a cumbersome and difficult process.

Actions

The issues touched upon in this paper will need to be addressed in the development of global electronic commerce, to clarify the legal situation and reduce legal risks. But what can CEOs do today to minimise the risks involved in entering into e-marketplaces and business to business e-commerce? Some key actions can be identified:

Create and implement a clear legal infrastructure parallel to Your information infrastructure. Enter into contracts with all parties before actually entering into commerce.

Follow the development in the specification of XML based vocabularies and try to streamline your legal infrastructure to cover up weaknesses in the vocabularies.

Investigate the use and development of trusted third parties in e-commerce. Is there adequate services in this arena today? Can adequate services be expected and can they be easily implemented in your legal/information infrastructure.

Always ask what the legal design of a marketplace looks like before entering into that marketplace. Aside from the questions touched upon here, try to ascertain, first and foremost, liability distribution.

There is exciting work being done in this area today. Companies such as IBM are well aware of the difficulities and work with XML to establish infrastructures that offer the same kind of stability that was present in EDI-solutions.

See the development of tpaML within IBM, for example at http://www.ibm.com

Ultimately the devlopment in the XML area will be turbulent and fast. But business interaction must remain reliable and steady. Therefore it is important to oversee and work with these issues in an early stage. Justice has a peculiar quality: it is always more expensive after the fact.

Acknowledgements

I am indebted to Dr Cecilia Magnusson-Sjöberg for her suggesting that I write this paper and also for her comments on earlier drafts.

Bibliography

1	CBL 2.0 Specification

2	cXML 1.0 Specification

3	Kotok, Alan “Introduction to XML and EDI” in XML.com [http://www.xml.com/pub/1999/08/edi/index.html] (2000-03-21)

4	LegalXML consortium webpage. [http://www.legalxml.org/Information/LegalXMLWorkgroups.asp](2000-03-21)

5	Mc Grath, Sean XML by example - Building E-commerce Applications (Prentice Hall, New York 1999)

6	Magnusson Sjöberg, Cecilia. Critical Factors in Legal Document Management: A study of standardised markup languages. (Stockholm: Jure, 1998)

7	Seipel, Peter Juridik och IT - En inledning till rättsinformatiken (Stockholm: Norstedts 1997, 6:e uppl)

8	Timmers, Paul Electronic Commerce — Strategies and Models for Business-to-Business Trading (Wiley, New York 2000)


	XML-related intellectual assets		Table of contents		Indexes		XML &, the enterprise