I'm suggesting a new "super-standard" based on both works, with a
modular design just like ebXML Registry has now. A robust registry
needs both replication and federation, so that isn't an issue to me.
-Matt
On Friday, September 27, 2002, at 08:42 AM, David RR Webber -
XMLGlobal wrote:
> Message text written by Matthew MacKenzie
>>
> As for coexistence -- I can't see that, not from a business/sales
> perspective at least. <
>
>>>>>>>>
>
> Matt,
>
> Now you've got me putting on my Marketing / Bus Dev hat!
>
> The big difference I see is the formal replicated v federated models,
> coupled with the tModel/WSDL v ebXML architecture stack.
>
> And this then comes back around to the business needs.
>
> So if you are trying to deploy an eMarketplace with lots
> of eCommerce sites and you want a strict and formal
> member directory / participation control structure - with
> simple push/pull content interactions - then UDDI makes sense.
>
> If you are looking to build a cross industry supplychain
> B2B world with multi-threaded business processes
> between many collaborating peers then ebXML gives you that.
>
> Similarly if you are looking to document reference industry
> domain vocabularies, transactions and classifications
> and codelists, then ebXML registry is the right choice.
>
> Does it makes sense to keep complete separation for
> ever here? Clearly three years from now we would like to
> see a common infrastructure - and providing support
> for the two mechanisms - replicated / federated.
>
> But as a marketing person - I'm seeing you'd make the
> product modular - so customers can buy a simple
> base registry, and then step-up to more functionality
> as they need it.
>
> DW.
