Regarding providing TModels of registry artifacts.... My thought is that
it is beyond the scope of our TC to define TModels for CPPs, BPs and the
like. These should be defined by the appropriate ebXML committee (i.e.,
the Big UN/CEFACT committee...(the name escapes me)). What our
TC discussed on our conference call was to limit our TModel definitions to
only those that would help ebXML Registries be found and defined in a
consistent manner.
--lisa
At 02:42 PM 8/21/2001 -0400, David RR Webber wrote:
>Message text written by Scott Hinkelman
> >The answer lies in firstly obtaining official liaisons between UDDI and
>OASIS Registry
>that share the vision of a cohesive Reg/Rep environment where value is
>added
>from both organizations.<
>
>Scott,
>
>Good call.
>
>Another major concern here is the relations of the two entities.
>
>We have been asked by UDDI to provide TModels of registry
>artifacts. Within that scope this does not appear to be
>unreasonable.
>
>Clearly the role of ebXML is to define and manage
>the business process artifacts, while UDDI is providing
>directory services around the business services companies
>are providing, and thru using those ebXML business process
>artifacts (up to and including CPP and CPA). Some overlap
>is inevitable, and therefore the interactions need to be
>understood and coordinated.
>
>However - here's the rub. The ebXML work is public domain,
>while the UDDI is not. Therefore we have to avoid at all costs
>any situation where work is being developed within UDDI and
>then being presented to ebXML for adoption.
>
>The best outcome would be for UDDI to create a public
>process which we could work thru.
>
>Thanks, DW.
>
>----------------------------------------------------------------
>To subscribe or unsubscribe from this elist use the subscription
>manager: <http://lists.oasis-open.org/ob/adm.pl>
