Commerce

Type

The commerce element includes a type attribute used to specify the generic type of business communication, such as "request for quotes", "price quote", "purchase order", "invoice", "receipt", etc. This type attribute will be used to guide the interpretation of the included elements.

<com type= String > . . . </com>

Dates

The commerce element may contain one or more dates specified with the date element. The date element includes the label attribute to signify the type of date that is being communicated. This may be the time of the message, order date, delivery, deadline or any other time relevant to the transaction.

Entities

There are many people, companies, organizations and governments that may be involved with a transaction. For a purchase order or delivery there may be the manufacturer, distributor, consignor, shipper, insurer, receiver, point of contact, etc.

To communicate the many entities involved with a transaction PML allows one or more entity elements within the transaction specification. Each of these entities may have various roles that are communicated with the role element, which is part of the entity definition.

We can already see how this modular approach allows a wide variety of communication. The entity elements may contain a timestamp or ts element, which encodes certain dates, times and durations. We could, for example, specify a certain shipper for one week and another the following week - all within a single business message.

Items

At some point, a business message must contain some description of a product or service. For an price quote, invoice, receipt or packing slip, there is usually a list of items, quantities, descriptions, unit prices and total amounts. We will accommodate this by introducing a generic item element.

The item element includes an optional epc attribute for identify the particular product or service and for references these with external PML descriptions. In other words, all the elements of PML specification are essentially available within the item list of a particular business transaction.

The item element will, however, contain some explicit PML elements. These are a measurement or msr element used to describe the quantity and amount, a price element to describe the intended price with respect to the specified msr element and a present element used for the name and generic description of the product or service.

The msr (measurement) and present elements are described in previous chapters. The price element contains a unit attribute for price unit, such as "USD" , "FF" , "DM" , "YEN" , or other currency, as well as a floating point number representing the amount of that currency in the body of the tag. Again modifiers such as the ts (timestamp) and access elements may be introduce into this (and any other element) to more precisely restrictive times and user accessibility.

Terms

Every com element may include one or more term elements, which are simply text strings containing the terms and conditions for the business transaction. Given the wide variety of possible terms - and the templated nature of most of these terms - no further structure or formatting is included in these elements.

<term> . . . </term>

. . .

<term> . . . </term>

 

 

Negotiation

Most intentions, reasons and justifications are impossible to communicate in a business document. Is the price too high? Is the delivery too late? Can the shipper be trusted? All of these must be communicated (when the party can be reached) on the phone or in person.

We propose to include this implicit communication explicitly within the Physical Markup Language. We define a negotiation or neg element in the communication specification, so that every element of the business communication can be negotiated - from price to delivery date, from shipper to insurer. The neg element includes options designed to communication intention, importance, level of agreement and limits of negotiation with respect to an element.

The neg element allows the communication of the negotiability and intent between trading parties. A agreement, or arg attribute, communicates agreement or disagreement on a particular term in the business communication. In this case the agreement attribute is a boolean - either true or false . In other words, does a party feel they have reached agreement on this term or not.

The value, or val , attribute communicates the level of importance of a particular item. Often, though parties disagree, some terms and conditions are more important than others. The value attribute is a simple measure that may be used to communicate importance. In this case, we simply allow a number between 0 and 1, where 0 is of no importance and 1 is of highest important. Clearly the exact interpretation of these values depend on the parties and the particular transaction, but it does afford some mechanism to communicate priority (in other words, a collection of values within a business communication can be used to rank importance).

An acceptance, or accept attribute, is similar in that it presents a qualitative range, though in this case is intended to communicate the level of agreement. Where 0 represents no agreement and 1 complete agreement. Again the absolute values are less importance, than their comparison within a business documents.

Finally a tolerance, or tol, attribute is intended to communicate the level to which a term may be negotiated. Some terms for some individuals are non-negotiable . In this case the tolerance would be 0. Other terms may have some give, flex or fudge. In a business negotiation, one may wonder why a party would every reveal the level of flexibility. Give on one term to receive better terms on another, however, may be an answer. In any case, we include this attribute in the negotiation term should parties wish to communicate this intent.

Flexibility

Finally, we introduce into every business communication one or more other business communications or com elements. In this way complex business transactions may be formed by nesting message within a message. Rich and detailed product offerings, for example, could be formed by constructing "package" deals or "special offers."

In this case, the Physical Markup Language commerce element assumes any included commerce element inherent all the terms and conditions of the parent (unless otherwise specified). In other words, the terms, conditions, entities, dates, times, etc., do not have to be repeated for subordinate com elements.