Re: Help needed on using ebXML Registry

["William J. Kammerer" <wkammerer@foresightcorp.com>]

Rosita Marin is "trying to understand how products and services are to
be described in a ebXML Registry."  She has "to describe products and
services of a telecom service provider."

Farrukh Najmi explains that "Unlike other registries (e.g. UDDI), the
ebXML Registry specs do not describe how products and services are
represented in the registry."   Farrukh is "not aware of any ebXML spec
defining product description," though he suspects "[the] closest area
may be Core Components team."

I can assure Farrukh that the ebXML Core Components team has not devised
any product catalog - only an attempt at documenting how to "discover"
the core components of such an animal if the need ever arose.  In the
meantime, Rosita may have to find some standard product catalog format
that suits her purposes.  I would suggest the UN/EDIFACT PRICAT
Price/Sales Catalogue Message (or its ANSI X12 analog, the 832 Price
Sales/Catalog), only because it works.  In the U.S., the
Telecommunications Industry Forum (TCIF) has developed an 832 guideline
for the telecommunications industry; see their General Procurement
Guidelines at http://www.atis.org/atis/tcif/edi/psc/psc_guid.htm.

There's no reason "legacy" EDI guidelines can't be handled by the
flexible ebXML Registry and Repository.  And the 832 or PRICAT documents
themselves can be stored there, or more likely transported using the
ebXML Messaging Services.  For more information on transporting "legacy"
EDI over the Internet using ebXML Messaging Services, see
http://lists.ebxml.org/archives/ebxml-transport/200104/msg00099.html.

If Rosita is fixated for some reason on using XML for the product
catalog business document, she can refer to the ebXML Catalog of Common
Business Processes v1.0, where, in addition to the X12 832 and the
UN/EDIFACT PRICAT, the OAG BODs for Price Catalog Procurement Management
are listed for reference (128_sync_catalog_001,129_get_catalog_001, and
130_show_catalog_001).  Though the RosettaNet Product Catalog Update
PIPs are not listed, I think applicable messages are in Segment 2A:
Preparation for Distribution - though they may not be appropriate for
describing the products and services of a telecom service provider.
Other XML'ized product catalog messages can be found at the XML Cover
Pages at http://xml.coverpages.org/, such as OCP - Open Catalog
Protocol.

In addition, one mustn't overlook xCBL, at http://www.xcbl.org/, which
has the political momentum behind it - if not necessarily the technical
merit - to become the ebXML business message library.  xCBL includes a
ProductCatalog document, which "[covers] the pricing and product
descriptions for catalog content, and has a self-describing set of
extensions for further characterizing products and services offered. May
be used to transfer self-configured product characteristics as well."
The trouble with the xCBL product catalog, as with any XML rendition,
would be its sheer bulk - as the May 2001 xCBL User's Group Newsletter
apologetically explained:

   A number of factors resulted in a ProductCatalog structure
   that is in some ways inconsistent with the bulk of xCBL,
   although this is not true in all cases (many standard xCBL
   constructs are used in ProductCatalog). The first major
   design driver was file size: unlike most transactional
   documents, ProductCatalog instances will, in many cases,
   not be merely large, but huge. The markup becomes a
   significant burden when handling documents of larger size,
   slowing processing times. Because of this, the markup in
   ProductCatalog is in general much sparser than in other
   document definitions. In many cases, although it might have
   been slightly easier to process with deeper nesting of
   containers, etc., these were omitted as being more trouble
   from a size perspective than they were worth from the
   standpoint of a developer. Secondly, many aspects of the
   ProductCatalog document are more "typical" XML DTD
   constructs than straight xCBL constructs. These include
   such things as the use of ID/IDREF, and the use of
   xml:lang. A large number of catalog content processing
   systems have solved problems of arbitrary product attribute
   handling in ways based on XML DTDs, rather than on XML Schema
   languages. These approaches, although inconsistent with the
   rest of xCBL, are supported in the ProductCatalog document
   to allow easier adoption of the format.

Finally, Joel Munter may be overloading the term "Services."  He says
"The UDDI specifications DO DESCRIBE how SERVICES are represented within
the UDDI Registry."  True enough, for web or technical services (e.g.,
"I support ebXML"), but not the "business" services Rosita may have in
mind.  UDDI would be able to locate trading partners by NAICS or UN/SPSC
codes based on telecommunications industry products and services.  From
there, she could find the ebXML Registry and Repository for the sellers
where the business processes for obtaining a product catalog are
described.  For more information, see the White Paper "Using UDDI to
Find ebXML Reg/Reps."

William J. Kammerer
FORESIGHT Corp.
4950 Blazer Pkwy.
Dublin, OH USA 43017-3305
+1 614 791-1600

Visit FORESIGHT Corp. at http://www.foresightcorp.com/
"accelerating time-to-trade"