Re: [ebxml-dev] Discovery

[Farrukh Najmi <Farrukh.Najmi@Sun.COM>]

We are missing an important point  in this discussion. I assert that that the OASIS
ebXML CPA/CPP and Registry specs and functionality would be not an iota different
than what they are right now whether this automated discovery of partners was the
dominant use case tomorrow or a pipe dream.

The two specs are designed to support a lot more than this controversial automated
discovery use case.

One can believe that just-in-time (JIT) partnerships are a looney idea. One can also
believe that while it may seem bizarre by today's business standards, if the right
conditions exist in the future, JIT partnerships will be the norm and not the
fringe. However, one cannot believe that ebXML as a whole is a fantasy if one thinks
JIT partnerships is a crazy idea.

To discredit ebXML because it *CAN* support automated discovery of partners is
missing the point at best and creating pure FUD at worst..

--
Regards,
Farrukh

Mike Rawlins wrote:

> Can we not discuss this without resorting to more hype, and being a bit more to
> the point?
>
> "Nieman, Scott" wrote <snipped> in response to William Kammerer's note:
>
> > >>   This "discovery" crap sounds like e-marketplace hype which
> > >>   only analysts and VC would swallow. If Ford wants to
> > >>   "discover" a direct supplier, their own buyers and
> > >>   engineers know where to look - they don't need ebXML.
> >
> > William, your examples are too typical of big business, which are
> > unfortunately riddled with point to point integrations.  There are examples
> > that could be placed at a consumer or retail level.  For example, what if
> > William Kammerer wanted to buy a Peruvian sweater, and his Internet search
> > found sweater that he could buy directly from a woman in Peru.  Instead of
> > that woman getting 10 cents/ day to make the sweater, she is getting a
> > reasonable sum of money directly from you using PayPal.
>
> I think you need a better example, Scott.  The primary focus of ebXML is B2B, my
> application to your application.  Your example is B2C, William sitting at a
> browser to the Peruvian woman's web site.  Try again.
>
> >
> >
> > This has been the vision of UN/CEFACT for ages, to help the emerging
> > nations.  If it wasn't for the middleman and big business, we would not have
> > sweatshops.  These thoughts also freak out the e-marketplace vendors.
>
> (CEFACT has been around for ages?  It may seem that way to some of us, but I
> think it has only been about 6 years or so in its current incarnation.)  Sure,
> blame it all on middlemen and big businesses.  Just as the poor will always be
> with us, I expect that sweatshops will always be with us.   e-marketplace
> vendors are already so freaked out about their low stock prices that I don't
> think any of this bothers them at all.  Can we stay on point?
>
> >
> >
> > The vision of the ebXML Registry has been distributed, which means many
> > things:
>
> Yes, the vision has been distributed.  When will the specification support a
> fully distributed registry?
>
> >
> > 1) every web site could have an ebXML registry - ideally part of the
> > everyday plumbing (I am happy that apache is taking this on),
> > 2) every web site/RA can control its own destiny - creates its own
> > classification schemes, link its assets to nodes in other classification
> > schemes, etc etc, to create a "web" of associations
>
> OK, now instead of worrying about dealing with different EDI implementation
> conventions, we're going to have to deal with everyone's different
> classification schemes in their registries.  I think we're just moving the chaos
> around a bit, and not fixing it.
>
> >
> > 3) distributed technology like peer-to-peer (P2P) popularized by Napster can
> > relay searches to other ebXML Registries in the peer community (the
> > distributed part still needs work, as P2P concepts need to be standardized
> > - ideally in XMLP), and each registry can respond directly to the requestor,
>
> So, ebXML Registry is not going to use the ebXML MHS anymore and will use the
> XMLP???  Yes, I think there's quite a bit of work left to do here.
>
> >
> > 4) it eliminates the middleman - no brokers, no exchanges (sorry folks, that
> > model will eventually be like the dinosaur)
>
> Technology in and of itself will never eliminate the middleman - ask any produce
> wholesaler.  In fact, some exchanges and brokers have been created by technology
> because technology has made them practical.  Can we focus on some reasonable
> benefits and not wild, unsubstantiated claims?
>
> >
> >
> > As far as your example, your are correct that these point to point
> > relationships exist, but they will exist for a long time.  But if I am a new
> > vendor, and if I can associate my part I manufacture as a
> > substitute/alternative to a specific node in an AIAG classification scheme
> > (perhaps by a part number taxonomy), my part MAY come up in a search if the
> > previous manufacturer is continuously late on shipments, and/or has a poor
> > quality record.
>
> Yes, and we have to acknowledge the fact that Ford, Chrysler, and GM use
> different part numbering schemes.   It's a very nice vision, but as always the
> devil is in the details.
>
> >
> >
> > Discovery IS a good thing.
>
> I fully agree, I just think there are practical limits (read ROI) to what we can
> do with the technology today.
>
> --
> Michael C. Rawlins, Rawlins EC Consulting
> www.rawlinsecconsulting.com
>
> ----------------------------------------------------------------
> The ebxml-dev list is sponsored by OASIS.
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.ebxml.org/ob/adm.pl>


begin:vcard 
n:Najmi;Farrukh
tel;work:781-442-0703
x-mozilla-html:FALSE
url:www.sun.com
org:Sun Microsystems;Java Software
adr:;;1 Network Dr. MS BUR02-302;Burlington;MA;01803-0902;USA
version:2.1
email;internet:najmi@east.sun.com
fn:Farrukh Najmi
end:vcard