Re: Usage of ebXML "identification.type" in application software

[jfarmer@ic.net]

At the OMG, in the context of the Person Identification Service (PIDS)
specification, we handled ID structuring as follows ( in interface
definition language)

struct QualifiedPersonId {

DomainName domain;

PersonId id;


A Qualfiied ID is an ID qualified by its identifier "domain" (rooted in
either a globally-unique namespace or literally "Other" for localized use).
The domain name may include (embed) additional substrings to represent the
logical entity class being keyed (like patient, customer, etc) as well as
the ID-assigning organizaiton, possibly as a DUNS or IP domain.  Personally,
I would include such elements explicitly (Entity Class and Assigning
organization (which needs a qaulaified Identifier for itself).

The PIDS spec is catching on fast, and all other OMG specs since 1997 have
keyed "persons" using the PIDS qualfiiedID structure.  Therefore I mention
these points in case you want to leverage against and.or harmonize with the
PIDS work.

Jon Farmer
Care Data Systems

----- Original Message -----
From: "Todd Boyle" <tboyle@rosehill.net>
To: <ebxml-dev@lists.ebxml.org>
Cc: "ebXML Core" <ebxml-core@lists.ebxml.org>
Sent: Saturday, June 02, 2001 4:23 PM
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>
>