Re: [uddi-spec] Draft TN: "UDDI as the registry for ebXML components"

[Max Voskob <mvoskob@msi.com.au>]

Keisuke and all,

I think Keisuke has done a great job with this TN. Thanx for that!
I have a few comments tho.

1. line 53
Is it applicable to v2 only? Can't see any reason why it can't be applied to
v3 as well.

I would suggest to modify the layout of a TN template so we can specify what
UDDI versions the TN is applicable to and if it's applicable with
reservations or exceptions.

2. line 63.
My understanding is that ebXML does define the way and provides the means
for that in form of their RegRep spec.

3. Section 1.2 Goal
Do we try to substitute ebXML RegRep with UDDI?
It's not mentioned directly, but this is the impression I got after reading
the whole doco. Can't see anything wrong with that. I know some businesses
that would be happy to use UDDI with their ebXML implementations.
On the other hand, UDDI is more specific than ebXML RegRep (RegRep was
designed as a registry of anything) so it can't really substitute RegRep yet
and I doubt ever will in its current form.
I'd suggest to take a look at the draft of
uddi-spec-tc-tn-ext-taxonomies-20021205 TN. The TN is available at
http://lists.oasis-open.org/archives/uddi-spec/200212/msg00005.html.
I believe that a much better level of interoperability can be achieved if
Keisuke's TN goes side by side with the other TN I mentioned above. At the
end of the day, isn't interoperability the ultimate goal?

4. Interoperability and ownership of taxonomies.
Another crazy suggestion!

Why don't we give control and ownership over the ebXML taxonomies (TX) and
identification systems (IDS) to ebXML?
If there was a common way of describing taxonomies and id. systems (see a
proposal at
http://lists.oasis-open.org/archives/uddi-spec/200212/msg00005.html) then
ebXML TC or any of their sub-TCs can develop whatever TXs and IDSs they need
and publish them for use within their community. In this case they can
maintain ownership and full control over the TXs and IDSs, update, version
and deprecate them as their community needs. UDDI only provides the means
for doing so.
To me this scenario looks like a bit of interoperability between the
standards / frameworks.
The question is ... will ebXML community be interested in using UDDI as
their discovery mechanism? :)))
Don't forget they use ebXML messaging in many cases and this is where UDDI
is missing out on them.

Cheers,
Max Voskob

----- Original Message -----
From: "Keisuke Kibakura" <kibakura@jp.fujitsu.com>
To: <uddi-spec@lists.oasis-open.org>
Sent: Friday, January 10, 2003 6:38 AM
Subject: [uddi-spec] Draft TN: "UDDI as the registry for ebXML components"


> All,
>
> Please find attached my initial version of the TN "UDDI as the
> registry for ebXML components".
>
> I have to apologize that it is out so late and consumed your review
> time before today's telecon.
>
> Plaese review and send comments to the list or me.
> Any comments are welcome!
>
> Regards,
>
> --
> Keisuke Kibakura
>
>