Re: Help needed on using ebXML Registry

[David Lyon <djlyon@one.net.au>]

William,

A fine analysis of ebXML and some good links to other sources for EDI and
XML information.

One gets the impression however from your posting that we shouldn't be
looking to ebXML for much at all because so much of it has already been
catered for elsewhere, especially within EDI. This isn't a very positive
endorsement of ebXML.

The reality is that people are/were looking to ebXML to provide some sort of
replacement to the now ancient art of EDI. Something that would be simpler
to implement/operate and allow larger numbers of companies to participate in
electronic trading than had previously been possible.

ebXML gave the promise of being able to do this. I read one press release
saying that 850,000 retailers (through Industry groups) had endorsed ebXML.

Really, if people ask for help on getting a simple thing like a product
catalog going, the last thing they want to hear is "go off to EDI, 'cos it
works". For SMEs at least, using a X.12 product catalog simply *doesn't*
work, you really should try one day and see how far you get.

Sure, XML catalogs can get big, but only in large organisations. Small and
Medium sized enterprises sell less products (on average) and don't have the
same size problems you talk about.

In fact, with computing power as it is right *now*, the average new home
computer with a 40G hard drive has enough space to hold *every* single
catalog from every single company in the world. Do the sums.

Do the sums:- the IBM Linux wristwatch has enough memory to hold an
inventory of over 100,000 product line items. So instead of looking back to
the ancient art of EDI, we should be looking to addressing what can be done
with the vast processing power of the computers now.

That's what people are looking to ebXML for. It seems to me that you are
just wasting your own time trying to send them to the dark dungeons of EDI.
Nobody likes that stuff anymore, but it does still have a place in large
organisations, I will grant that.

David Lyon



----- Original Message -----
From: William J. Kammerer <wkammerer@foresightcorp.com>
To: ebXML Discussion <ebxml-discussion@lists.ebxml.org>
Sent: Monday, May 21, 2001 4:53 AM
Subject: Re: Help needed on using ebXML Registry


> 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"
>
>
>
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: ebxml-discussion-request@lists.ebxml.org
>