[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Usage of ebXML "identification.type" in application software
Usage of ebXML identification.type in application software
I would like to submit for discussion, an information model for the
practical handling of identifiers from global product and party lists,
by application software.
The ebXML Core Component, "identifier.type" is a suitable starting point
for small and medium enterprises conducting business over the internet.
It is an appropriate solution for working with various lists that are
outside the control of one's company. I refer to Core Components
Structure and Naming convention v1.04
http://www.ebxml.org/specs/ebCCNAM.doc and
http://www.ebxml.org/specs/ccSTRUCT.xls which defines id type as,
"A character string to identify and distinguish uniquely, one instance
of an object in an identification scheme from all other objects
within the same scheme together with relevant supplementary information"
This CCT (core component type) appears to be intended for representing
DUNS numbers, EAN and UN/SPSC ids, and Ids of UDDI businessEntity's.
There will be hundreds of these schemes. The business objective is to
achieve practical usage of these IDs in a business system, and the means
to resolve them into their meanings by querying these list providers,
and the means to store them even though their native information models
are divergent.
The most important users of global list data are obviously B2B interactions
(the order, invoice, ship notice, etc. and newly emerging TP and BP
architecture
which does not include internal application integration.
However, global identifiers are also essential in internal (A2A) integration
and in handoffs between any BCM and the internal applications.
For example an accounting system consists of three components.
GLtransactionSet,
contains 1 or more GLtransaction's, contains two or more GLentry(s). The
OMG's 1998 GL calls them "ledger", "transaction" and "entry". I would
have called them ledger, GlHeader, GlRow. The ebXML or EWG will sooner or
later issue their naming of these as Core Components. Naming is unimportant.
Within a GL entry, I'm using the "identifier.type" and its related data
elements (below), to represent all IDs from reference lists, including
party,
product, service, orgUnit, GL account, and so forth.
SMEs use GL-like systems as their integrated platform for financial
reporting, tax reporting, cash management, and maintenance of payables
and receivables. A GL is a service platform for storage of whatever
you've done, supporting queries to support business processes and
settlement, and generating some reports. There are no single-entry list
systems left in the SME market for accounting software. Everybody uses
accounting software which enforces double-entry.
nuffa this. Now you know the context.
- - -
Most Identifiers in a GL need to be maintained in a way that is
accessible to external parties or applications outside the Owner's
business system. The expectations and requirements of these external
entities cannot be controlled or predicted.
At the same time, servicing the expectations of external parties is
mandatory. It is my expectation that SMEs who can conduct business
electronically, with correct and timely identifiers for products and
parties, will get lower admin costs and improved access to supplier or
sales markets.
I see two kinds of Identifiers.
(1) global lists, such as DUNS, UN/SPSC etc. and
(2) private lists such as a supplier's part numbers, or your own party
codes, or GL account codes or Project and Activity codes, etc.
My thinking is that an Identifier object should handle both public and
private lists. THIS IS IMPORTANT: All applications even in small
companies, will be required sooner or later to respond to queries from
other business modules or 3rd parties about the contents of a list. To
begin with, party data is almost always crucial to more than one
application. Consider the alternative: monolithic software like
Quickbooks having no interfaces for sharing customer or supplier lists.
Once you realise the inevitability of sharing list data, the question
becomes, "why should we create separate objects to manage private lists,
in addition to the objects that handle public lists?" Private lists
are just public lists having no shared permissions.
Another question is "Why should every different application design
software objects to represent exactly the same stereotype, to maintain
the same "identifier.type" entities? Everybody must access the same
public lists in the same way.
Now, reason this with me: the "public list authorities" do not provide
public query interfaces, in a standard way, and their data records
are different, even for the same kinds of things, such as a party or
product. Some of them are not XML.
Today, the individual business or web services provider has two choices
in beginning to use global list namespaces:
- buy or build software capable of dealing with a whole bunch of
separate, primary list providers (i.e. some big EAI or ecommerce
middleware), or,
- outsource the whole problem to a list aggregator or repository
provider, that may be able to get a handle on this whole problem and
provide you with a single interface to many lists, for a single price.
The ebXML community represents a third choice, if we discuss just a
bit of standardization in how we resolve identifiers. We should actually
share UML, XML and software code to improve the standardization of
access to list data.
I'm dreaming perhaps, that a standard set of expectations from application
software might influence the primary list providers to service them.
The list providers may benefit as much as SMEs in this regard.
As a practical matter, for the little guy to conduct business on the
internet we need a place we can trust, to resolve an Identifier into its
meaning, so that we can get down the road and conduct business with 3rd
parties, and we cannot allow the list data to be captured by anybody in
a way that imposes undue costs.
Most of small business does its discovery and negotiation and credit
evaluation outside the internet and this will continue basically
forever. As soon as they have mechanisms for exchanging list data Peer-
to-peer, actually, they're ready to do business. It is much preferred
that big Directory providers provide global namespaces, but until the
big players play fair and give us global directories, SMEs should be
encouraged to exchange Party and Product data privately, and directly,
between their systems with ebXML Core Component vocabulary.
I'm just talking common sense here, like, how quickly can I keypunch the
customers' or suppliers' "DUNS:55555555555" number into my application
and get a view of the party information, create the order or shipment
etc. and store a snapshot of the party information even tho it is all
different shapes from different providers. Personally, I view the
existence of a single central list as almost a show stopper because it
will obviously be exploited by its operator sooner or later. SMEs have
decades of experience and they are very very cynical. The SME deals
with one hustler after another, all day long. Customers, suppliers,
employees, service providers, the professions, the government. Global
corporations have little understanding of the level of cheap gimmicks
and hucksterism in small business in the western united states. Small
businesses assume the worst, in motivations behind somebody like Microsoft
trying to take over their banking or business software, or DUNS charging
them fees for their own customer list. There have to be competitive,
parallel lists. This cannot happen unless there is a standard vocabulary
and software model to talk with public lists.
This object must furthermore apprehend that all the lists have a
different record format or schema. In my own view, the providers would
have to be nuts not to provide records in XML format with accompanying
XSLT sheets for human reading, and for transformation straight into/out
of ebXML CCTs.
Any list data for which mappings are not available, can be mapped into
ebXML Core Components by users at some cost. It is essential that these
mappings be shared and reused, globally to bring down everybody's
average costs. See my earlier post, about harvesting mappings after the
mapping work has been done by the end user.
http://lists.ebxml.org/archives/ebxml- core/200104/msg00372.html
It is also possible of course, to capture the data record itself and who
would be the best party to recapture their own data than its owner?
Under today's laws you have a right to your own bank and credit records,
and you can empower a service provider to go after that data and
thereafter maintain it in repositories that have query interfaces, where
YOU control access to the data, instead of the bank or credit agency.
You will thereby grant views to customers and suppliers in ways that
provide better commercial terms, instead of having the megabanks selling
it to mass marketers. This can be a one-click deal. Webledgers will
certainly do this kind of service.
Future stuff; I hope that someday, these isolated identification schemes
should collapse into a single, giant 64-bit GUID system. All records of
all types could be stored in a globally visible file space such as a
webdav server that is globally visible. The author could provide access
to any particular record, schema, transformation, or transaction by
sending the GUID and the key to the intended recipient.
Anyway --I am describing a framework to go forward in a world where all
the codelist agencies are allowed to do their things, and assumed to be
balky and noncooperative and non-standard and barely functional. I am
suggesting that intelligent applications on the client side can change
this whole picture by creating a liquid market in list providers. Data
maintained in sub-optimal ways would gravitate back into highly
functional repositories, under the direction of its owners. Improving the
liquidity of the market for list data is the goal of the XML schema I
am proposing below.
A free market for list data, in which Owners of the list data can move
it under their own control or into the public domain, will bypass
the privacy laws and all the other problems the magazines are whining
about in their assumption that information can only be controlled from
top-down. This kind of advancement requires the collective action
and coordination on the customer side of the list-provider / list-user
relationship. I cite the example of OAGI which has a customer council,
influencing the behavior of vendors.
Below is a model corresponding with ebXML "identifier.type" but with
some necessary extensions. I omitted the ebXML "identification. scheme.
agency. name" which is useless without a global namespace. Below is my
idea of the extensions. Comments and criticism welcome.
Todd
Todd Boyle CPA (425) 827-3107
9745-128th Av NE, Kirkland WA 98033
func architect, NetAccount AS, Oslo, NO
tboyle@netaccount.com http://www.netaccount.com/
tboyle@rosehill.net http://www.gldialtone.com/
<?xml version="1.0" encoding="UTF-8"?>
<!-- IdType from arapXML084x2.xsd discussion draft by T. Boyle -->
<xsd:schema xmlns:xsd="http://www.w3.org/2000/10/XMLSchema"
elementFormDefault="qualified">
<xsd:complexType name="Amount">
<xsd:sequence>
<xsd:element name="value" type="xsd:double"/>
<xsd:element name="currency" type="xsd:string" minOccurs="0"/>
<xsd:element name="qualifier" type="xsd:string" minOccurs="0">
<xsd:annotation>
<xsd:documentation>(original or functional amount if used in a GL
application)</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="IdType">
<xsd:annotation>
<xsd:documentation>same as ebXML "A character string to identify and
distinguish uniquely, one instance of an object in an identification scheme
from all other objects within the same scheme together with relevant
supplementary information"</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name="idContent" type="xsd:string" minOccurs="0">
<xsd:annotation>
<xsd:documentation>same as ebXML "A character string to identify and
distinguish uniquely, one instance of an object in an identification scheme
from all other objects within the same scheme." eg. 13ABC4234
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="idSchemeName" type="xsd:string" minOccurs="0">
<xsd:annotation>
<xsd:documentation>eg. DUNS, UNSPSC etc. Name compliant with ebxml
id.scheme.name (globally disambiguated by schemaUri below in case of name
collisions.)</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="languageCode" type="xsd:string" minOccurs="0">
<xsd:annotation>
<xsd:documentation>An ISO 639 code: the language of the idContent, or
its underlying record at idName or dataUri below. </xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="idName" type="xsd:string" minOccurs="0">
<xsd:annotation>
<xsd:documentation>same as ebXML. a character string. eg. widget,
EXXON, etc.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="version" type="xsd:string" minOccurs="0">
<xsd:annotation>
<xsd:documentation>version of the fullRecord, idContent, scheme
whichever is more granular. Enables a primitive integrity in distributed
applications</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="parent" type="xsd:string" minOccurs="0">
<xsd:annotation>
<xsd:documentation>another ID within the same scheme, of which this ID
is child. enables expression of hierearchy in a list.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="balance" type="Amount" minOccurs="0">
<xsd:annotation>
<xsd:documentation>total balance of GL account, project, party AR/AP
etc. associated with idContent, after posting this Entry</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="schemaURI" type="xsd:uriReference" minOccurs="0">
<xsd:annotation>
<xsd:documentation>an XML schema specifying the information model used
in the underlying records in the scheme (ie in dataUri).</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="dataURI" type="xsd:uriReference" minOccurs="0"
maxOccurs="unbounded">
<xsd:annotation>
<xsd:documentation>an RFC 2396 URI with query component which returns a
record from the IdScheme agency, network, application, filesystem, SQL
database, XML repository, etc.</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:schema>
<?xml version="1.0" encoding="UTF-8"?> <!-- IdType from arapXML084x2.xsd discussion draft by T. Boyle --> <xsd:schema xmlns:xsd="http://www.w3.org/2000/10/XMLSchema" elementFormDefault="qualified"> <xsd:complexType name="Amount"> <xsd:sequence> <xsd:element name="value" type="xsd:double"/> <xsd:element name="currency" type="xsd:string" minOccurs="0"/> <xsd:element name="qualifier" type="xsd:string" minOccurs="0"> <xsd:annotation> <xsd:documentation>(original or functional amount if used in a GL application)</xsd:documentation> </xsd:annotation> </xsd:element> </xsd:sequence> </xsd:complexType> <xsd:complexType name="IdType"> <xsd:annotation> <xsd:documentation>same as ebXML "A character string to identify and distinguish uniquely, one instance of an object in an identification scheme from all other objects within the same scheme together with relevant supplementary information"</xsd:documentation> </xsd:annotation> <xsd:sequence> <xsd:element name="idContent" type="xsd:string" minOccurs="0"> <xsd:annotation> <xsd:documentation>same as ebXML "A character string to identify and distinguish uniquely, one instance of an object in an identification scheme from all other objects within the same scheme." eg. 13ABC4234 </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:element name="idSchemeName" type="xsd:string" minOccurs="0"> <xsd:annotation> <xsd:documentation>eg. DUNS, UNSPSC etc. Name compliant with ebxml id.scheme.name (globally disambiguated by schemaUri below in case of name collisions.)</xsd:documentation> </xsd:annotation> </xsd:element> <xsd:element name="languageCode" type="xsd:string" minOccurs="0"> <xsd:annotation> <xsd:documentation>An ISO 639 code: the language of the idContent, or its underlying record at idName or dataUri below. </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:element name="idName" type="xsd:string" minOccurs="0"> <xsd:annotation> <xsd:documentation>same as ebXML. a character string. eg. widget, EXXON, etc.</xsd:documentation> </xsd:annotation> </xsd:element> <xsd:element name="version" type="xsd:string" minOccurs="0"> <xsd:annotation> <xsd:documentation>version of the fullRecord, idContent, scheme whichever is more granular. Enables a primitive integrity in distributed applications</xsd:documentation> </xsd:annotation> </xsd:element> <xsd:element name="parent" type="xsd:string" minOccurs="0"> <xsd:annotation> <xsd:documentation>another ID within the same scheme, of which this ID is child. enables expression of hierearchy in a list.</xsd:documentation> </xsd:annotation> </xsd:element> <xsd:element name="balance" type="Amount" minOccurs="0"> <xsd:annotation> <xsd:documentation>total balance of GL account, project, party AR/AP etc. associated with idContent, after posting this Entry</xsd:documentation> </xsd:annotation> </xsd:element> <xsd:element name="schemaURI" type="xsd:uriReference" minOccurs="0"> <xsd:annotation> <xsd:documentation>an XML schema specifying the information model used in the underlying records in the scheme (ie in dataUri).</xsd:documentation> </xsd:annotation> </xsd:element> <xsd:element name="dataURI" type="xsd:uriReference" minOccurs="0" maxOccurs="unbounded"> <xsd:annotation> <xsd:documentation>an RFC 2396 URI with query component which returns a record from the IdScheme agency, network, application, filesystem, SQL database, XML repository, etc.</xsd:documentation> </xsd:annotation> </xsd:element> </xsd:sequence> </xsd:complexType> </xsd:schema>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC
