Suitability of smbXML for BSP integration

Suitability of smbXML for Integration between internet BSPs (business service providers)

Todd Boyle
May 31 2000

The smbXML schema published by NetLedger and its trading partners May 12 ( http://www.smbxml.org/) is an important new standard for SMB's (small/midsized businesses) conducting business over the internet (comments). This short review identifies some of its differences from a number of other, leading XML schemas which are in use in B2B commerce:

- uses attributes extensively where other schemas use child elements,
- uses separate record types for the customer and the vendor, and,
- combines the street, state, postal code into a multi-line address field.

Whether these differences are a good thing or a bad thing is up to the user to decide. Some of these issues may be mitigated by XSLT translations and others may not.

The schemas chosen for the comparisons below are xCBL, cXML, BASDA EBIS, OAGIS, and ebXML drafts.

Most of the leading XML schemas seem to have a single "party" record. For example, Commerce One's xCBL, cbldocguide201.pdf page 771 contains the documentation for the Party in xCBL. I have scraped some lines out of the PDF, below.

Contents Party

@PartyID (optional) string The 1- to 50-character identification
number for the party (Note: If specifying more than one identification
number, use the ListOfIdentifier element instead)

@AgencyID (optional) AgencyCode The agency that issued the party’s
identification number (Note: If specifying more than one
identification number, use the ListOfIdentifier element instead) For a
list of agencies, see AgencyCode on page 153 If the desired agency is
not included in this list, specify an AgencyID of "Other" and use the
AgencyOther attribute to specify the actual agency name

@AgencyOther (optional) string The 1- to 70-character name of the
agency that issued the identification number, specified if the value
of the AgencyID attribute is "Other" (Note: If specifying more than
one identification number, use the ListOfIdentifier element instead)

NameAddress (optional) The name and address of the party

Identifier (optional) The identification number of the individual or
department Agency

@AgencyID AgencyCode The agency responsible for issuing the
identifier For a list of agencies, see AgencyCode on page 153 If the
list does not include the desired agency, specify an AgencyID of
"Other" and use the AgencyOther attribute to specify the actual name
of the agency

@AgencyOther (optional) string The 1- to 70-character name of the
agency responsible for issuing the identifier, used when the AgencyID
attribute has a value of "Other"

Ident string The party’s 1- to 50-character identification number

Name1 string The 1- to 35-character first line of the party’s name

Name2 (optional) string The 1- to 35-character second line of the
party’s name

Name3 (optional) string The 1- to 35-character third line of the
party’s name

Address1 string The 1- to 35-character first line of the party’s
street address

Address2 (optional) string The 1- to 35-character second line of the
party’s street address

Address3 (optional) string The 1- to 35-character third line of the
party’s street address

Address4 (optional) string The 1- to 35-character fourth line of the
party’s street address

Address5 (optional) string The 1- to 35-character fifth line of the
party’s street address

City string The 1- to 35-character name of the party’s city

StateOrProvince string The party’s 1- to 35-character state or
province

PostalCode string The party’s 1- to 20-character zip or postal code

Country CountryCode The party’s country code For a list of country codes, see...

ebXML is gradually being shaped into a single party record, if you read the core components list and docs. The file "data list_definitions2ISC.xls" came thru the list a couple weeks ago with this definition:

Party - a person or persons forming one side in an agreement or dispute. - A person or an organisation forming one side in an agreement.

Following message is typical consensus forming on the ebXML email list supporting a single party record:

From: owner-ebxml-core@lists.oasis-open.org behalf Of B.H.
Sent: Friday, May 26, 2000 2:18 PM
Subject: RE: XML Implementation spec

Arofan,

Does subclassing in core components mean something different
from subclassing in an object model?

For example, if I am an object of the Buyer subclass and then
I want to switch to being a Seller, I would need to change my
class (which is not supported very well in most object-oriented
languages). I would be better off being an object of the class
Party and adopting Roles of Buyer and Seller, which I can
change at will.

But maybe I am applying object-thinking, and you are not
using the concept "subclass" in an object-oriented sense?

Confusedly,
B.H.

-----Original Message-----
From: A.G.
Sent: Friday, May 26, 2000 4:08 PM
To: 'B.H.'; 'ebxml-core@lists.oasis-open.org'
Subject: RE: XML Implementation spec

Bob:
The point of subclassing is that the core information structure (the
"Party" information) would be the same whether the Party was acting as
Buyer or Seller. This way, it becomes possible to reuse the data
structure of the superclass in each of these otherwise disparate
cases. That is the whole point of subclassing - to allow re-use of the
information in cases where there is a different semantic associated
with the same bits of data. So long as the structure (at the level of
the super-class) is common, the semantic can be adjusted without
making interoperability impossible.

Cheers,

A.G.

-----Original Message-----
From: B.H.
Sent: Friday, May 26, 2000 1:26 PM
To: 'ebxml-core@lists.oasis-open.org'
Subject: RE: XML Implementation spec

E.N. wrote:
>Attached is a first draft of the XML Implementation Methodology
>specification.

Question: in this document, Buyer and Seller are subclasses
of Party. Is this the way the core component for Party will be
designed (I hadn't noticed it in other documents), or is that just
an example of how to implement subclasses?

To put a point on the question, how could the same Party
be a Buyer in one exchange and a Seller in another,
if Buyer and Seller are subclasses?

Thanks,
B.H.

Ariba's cXML has a detailed Supplier record, and several customer-like records such as BillTo, ShipTo, PCard, etc. Their address has separate lines for street, city, state, postalcode, etc. All of these are child element structures. Below are selected lines carved out of the cXML DTD:

<!ELEMENT Contact (Name, PostalAddress*, Email*, Phone*, Fax*, URL*)>
<!ELEMENT DeliverTo (#PCDATA)> 
<!ELEMENT Street (#PCDATA)> 
<!ELEMENT City (#PCDATA)> 
<!ELEMENT State (#PCDATA)> 
<!ELEMENT PostalCode (#PCDATA)> 
<!ELEMENT Country (#PCDATA)> 
<!ELEMENT PostalAddress (DeliverTo*, Street+, City, State?,
PostalCode?, Country)>
<!ATTLIST PostalAddress
name %string; #IMPLIED>

<!ELEMENT Address (Name, PostalAddress?, Email?, Phone?, Fax?, URL?)>

BASDA's invoice and order have fields for "supplier" and "buyer" but they are populated with child elements called "partycode", "address", etc.

<!ELEMENT SUPPLIER (PARTYCODE* , ADDRESS? , CONTACT* )>
<!ELEMENT BUYER (PARTYCODE* , ADDRESS? , CONTACT* )>
<!ELEMENT ADDRESS (NAME? , STREET* , CITY? , STATE? , POSTCODE? ,
CNTRYCODE? , COUNTRY? , ADDRESSLINE* )>

Rosetta has a "partner" record which is the same for their "toRole" and "fromRole" below.

<!ELEMENT toRole
( PartnerRoleDescription ) >

<!ELEMENT PartnerRoleDescription (
GlobalPartnerRoleClassificationCode? ,
PartnerDescription? ,
ContactInformation? ) >

<!ELEMENT GlobalPartnerRoleClassificationCode
( #PCDATA ) >

<!ELEMENT PartnerDescription (
GlobalPartnerClassificationCode? ,
BusinessDescription? ) >

<!ELEMENT GlobalPartnerClassificationCode
( #PCDATA ) >

<!ELEMENT BusinessDescription (
GlobalBusinessIdentifier? ,
GlobalSupplyChainCode? ) >

<!ELEMENT GlobalBusinessIdentifier
( #PCDATA ) >

<!ELEMENT GlobalSupplyChainCode
( #PCDATA ) >

<!ELEMENT fromRole
( PartnerRoleDescription ) >

<!ELEMENT ContactInformation (
contactName? ,
telephoneNumber? ,
EmailAddress? ) >

Selected elements of OAGIS DTD are as follows, which illustrate their approach to combining of parties into a "Partner" element, and illustrate their separation of address lines to separate elements:
http://www.openapplications.org/

<!ELEMENT PARTNER (NAME?, ONETIME?, PARTNRID?, PARTNRTYPE?,
SYNCIND?, ACTIVE?, CURRENCY?, DESCRIPTN?, DUNSNUMBER?, GLENTITYS?,
NAME*, PARENTID?, PARTNRIDX?, PARTNRRATG?, PARTNRROLE?, PAYMETHOD?,
TAXEXEMPT?, TAXID?, TERMID?, USERAREA?, ADDRESS*, CONTACT*)>

<!ELEMENT ADDRESS (ADDRLINE*, ADDRTYPE?, CITY?, COUNTRY?, COUNTY?,
DESCRIPTN?, FAX*, POSTALCODE?, REGION?, STATEPROVN?, TAXJRSDCTN?,
TELEPHONE*, URL?, USERAREA?)>

<!ELEMENT CONTACT (NAME, CONTCTTYPE?, DESCRIPTN?, EMAIL?, FAX*,
NAME*, TELEPHONE*, USERAREA?)>

In conclusion, smbXML differs from other, leading XML schemas as follows:

- uses attributes extensively where other schemas use child elements. for discussion of this issue,
see http://www.oasis-open.org/cover/elementAttr9804.html
- uses separate record types for the customer and the vendor, and,
- combines the street, state, postal code into a multi-line address field.

This review is not intended to be comprehensive. There are lots of other differences and nuances both obvious and subtle. For example smbXML includes all its business documents within a single XML schema, and its methods in another. Other XML vocabularies that are document based, have clearly defined schema for each type of document, which prevents elements intended for any particular document types or choreography from appearing in other documents legally.

smbXML is just a whole nuther animal. Based on the multi-line address decision (todd draws a puff on his cigar...) it appears aimed more at interfacing with Quickbooks than with other BSPs on the internet,

TB 5/31/00