Re: Help needed on using ebXML Registry

[Tim McGrath <tmcgrath@tedis.com.au>]

i must admit i am somewhat disturbed by the direction this thread is heading
(and david's understandable disappointment).  one point that is missing,
is that the work on defining the content of ebXML exchanges is not yet
completed.  ebXML (in its new guise within UN/CEFACT) will continue
this work.  Furthermore, there is a mis-conception creeping into the
debate which needs exposing.

I can only sympathise with anyone trying to get the high level perspective on ebXML, despite numerous attempts we have not managed to acheive this.  The documentation is overwhelming. May i start by clarifying what may be a misunderstanding of the strategy taken by ebXML.

To simply have ebXML specify an application such as a 'product catalogue' would be going back to what we already have - that is EDIFACT or X12 messaging.  This is not what ebXML is trying to do.

ebXML is a framework by which applications such as you suggest, can be defined.  what is also innovative about this is that ebXML allows you to formally define both the business processes and the message structures involved (something old EDI standards struggled with).  One trading group may define its structure and message flows for its product catalogue differently from other industries, organisations and/or regions.  This is where things like xCBL, EDIFACT, X12 (data structures) and RosettaNet, GCI, OTA, etc. (business processes), fit in.  They are examples of "things" ebXML needs to formally define.

Furthermore, each group may choose to catalogue and register these business processes and message structures in an ebXML compliant registry.  This would allow discovery and interpretation by others (either by human or machine processes).  Because these would use the same ebXML definition framework, there is scope for interoperability - ie recognising reusable processes and data.

To further clarify this, can i suggest you look at the “Direct to Customer Drop Ship Retail.” example used in the document "Business Process Analysis Worksheets & Guidelines v1.0" ( http://www.ebxml.org/specs/bpWS.pdf ).  There is also a document that shows how a complete business process can be specified in an ebXML framework, the "E-Commerce Patterns v1.0"  ( http://www.ebxml.org/specs/bpPATT.pdf ).  Although this document deals with a contract negotiation, i think you should be able to see how it could be applied to other applications as well.  If you want to see how these can then be catalogued into an ebXML Registry, such that others may understand (and adopt) this application, then i can also recommend the document "Catalog of Common Business Processes v1.0" ( http://www.ebxml.org/specs/bpPROC.pdf ).

to re-emphasise my earlier point, ebXML is not done yet (despite the spin being put on its status) - but it is on the right track.  don't let the current lack of working examples put you off, these are being built and will be deployed.

I firmly agree with you, the reality is that people should be looking to ebXML to provide some sort of replacement to the now ancient art of EDI (as preached by EDIFACT and ANSI). This must be simpler to implement/operate and allow larger numbers of companies to participate in electronic trading than had previously been possible.

They way to do this is by specifying the way things are defined, not by defining them in fixed patterns and forcing all participants to use the same processes.  If this specification is formalised and unambiguous (which is what ebXML is trying to do) then we can create a suitable match of business needs to technology requirements.  An SME will have differing requirements for their stationery purchases than their raw materials, which in turn difffer from those of another SME in another country, etc, etc..  It is OK to have differences, but these processes should be specified using a common framework, ebXML.

The ebXML framework will enable market forces then determine the appropriate 'product catalogue' to use, yet still allow re-usability of data and processes where appropriate.

I am pleased this discussion is underway (and from Australia as well!), the more debate we have the stronger the end result  However, lets keep the perspective correct.
 

David Lyon wrote:

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
>

------------------------------------------------------------------
To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: ebxml-discussion-request@lists.ebxml.org

--
regards
tim mcgrath
TEDIS   fremantle  western australia 6160
phone: +618 93352228  fax: +618 93352142