OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

regrep message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: RE: [regrep] Extramural Associations proposal


Farrukh,

I will not go into a tit-for-tat debate with you.  Some of you comments were
inflammatory and at times offensive to me and other great efforts by lots of
folks from many companies including yours and mine.  I respectfully request
that you leave your flames for private eMail.  Lets use this list for real
technical debate and substantive details.  

My argument has been consistent: If a capability exists elsewhere we should
attempt to reuse rather than reinvent.  I have not completely thought
through whether a cooperative use of UDDI's association makes any sense, but
I was simply suggesting that we look to existing before we create anew.
Thank for providing valid Use Cases.

Joel

-----Original Message-----
From: Farrukh Najmi [mailto:Farrukh.Najmi@Sun.COM]
Sent: Saturday, November 03, 2001 9:04 AM
To: Munter, Joel D
Cc: regrep@lists.oasis-open.org
Subject: Re: [regrep] Extramural Associations proposal


Joel,

I see a glaring inconsistency in your arguments against extramural
Associations.

On the one hand you question the need for extramural Associations below:

    "As an owner of an RegistryObject, I do not believe that I would want to
    allow other's to be able to "associate" me to other RegistryObjects
without
    my consent.  I understand that you added the "confirmation" section to
    accommodate this.  But this is after the fact.  You've stated that an
    association is not complete unless it is confirmed.  This multi-step
process

    is complex."

On the other hand (in the next paragraph) you say that OASIS ebXML registry
should not do this feature
because UDDI does:

    "I am again quite alarmed that this is a capability that already exists
in
    UDDI.  Rather than investigating ways to cooperate with existing
Registry
    efforts, this Oasis ebXML Registry specification effort is proposing to
add
    capability that already exists elsewhere.  This is a generalized version
of
    the UDDI publisherAssertions model and process."

So let me get this straight. The feature and use case was good enough for
you
when it was being done in UDDI V2. There was enough justification for its
need
in UDDI V2. But when a similar feature is being proposed for ebXML registry
V2
you question its need? Sound rather inconsistent.

Which is your real issue?
    a) That the feature does not make sense, OR
    b) That we cannot implement functionality that is in UDDI

We need extramural associations to address a valid use case in our registry.
Frankly, the argument that if UDDI does something, ebXML registry cannot do
it,
is wearing quite thin. For the record ebXML registry did Associations before
UDDI. UDDI "borrowed" that idea (among many others) from us and improved
upon
it. Well the extramural Association proposal improved upon UDDI publisher
assertions.

I should also mention that, as we speak, UDDI is working on  features such
supporting internal taxonomies. Well, should we in ebXML Registry go all
huffy
about it, cry foul, throw a tantrum, and say they cant do that?

We are an open forum unlike UDDI, and UDDI has freely "borrowed" from us and
duplicated our functionality. Why should you and a handful of other UDDI
folks
in ebXML Registry get up in arms whenever a feature is proposed for ebXML
Registry that happens to have something similar in UDDI? The last time you
did
this was for the Registration of Web Service (ROWS) proposal.

Let me close by publicaly airing a few assertions:

1. The features that we have proposed that you have cried foul over because
of
UDDI (ROWS, extramural Associations), will make our registry a success

2. My agenda is to make OASIS ebXML Registry be the best and most successful
registry in the world

3. Your agenda is to make UDDI registry be the best and most successful
registry
in the world

4. Both of us want closer cooperation between OASIS ebXML Registry and UDDI
(in
fact I want true convergence).

Please let us know if you disagree with any of the above assertions.

PS: See use case response inline below.

--
Regards,
Farrukh


"Munter, Joel D" wrote:

> Farrukh,
>
> While the proposal is well written, I could not find a clearly written Use
> Case for this new class of associations.  What you have written about the
> valid Use Case is:
>
> Line 73-77
> 4.5 Extramural Association
> The information model also allows a more sophisticated use case where a
User
> "u1" creates an Association "a" between two RegistryObjects "o1" and "o2"
> where association "a" is owned by User "u1", but RegistryObjects "o1" and
> "o2" are owned by User "u2" and User "u3" respectively.
>
> (imho) This is not a Use Case.  This is a description of the actors
> involved.  Can you please provide an English description of why these
actors
> would want to do this.  What is a business case where the would be valid?
> What sub-types of RegistryObject is this valid for?

One business case is that Company A submits an association between their CPP
and
Company B's CPP with associationType "ParterOf". In other words Company A is
saying they are a partner of Company B. The Association may or may not be
true.
In order fro it to be considered as truth Company B must confirm that indeed
theyt are a partner of Company A. Until the extramural Association is
confirmed,
the Association is not visible to any one but Company A and Company B.

All sub-types of RegistryObjects would be eligible for Extramural
associations
since all sub-types of RegistryObjects are eligible for current (intramural)
associations.

>
>
> As an owner of an RegistryObject, I do not believe that I would want to
> allow other's to be able to "associate" me to other RegistryObjects
without
> my consent.  I understand that you added the "confirmation" section to
> accommodate this.  But this is after the fact.  You've stated that an
> association is not complete unless it is confirmed.  This multi-step
process
> is complex.

This is essentially the same multi-step process as UDDI publisher
assertions.
Again it was good enough for you in UDDI. What is the problem in ebXMl
registry?

>
>
> I am again quite alarmed that this is a capability that already exists in
> UDDI.  Rather than investigating ways to cooperate with existing Registry
> efforts, this Oasis ebXML Registry specification effort is proposing to
add
> capability that already exists elsewhere.  This is a generalized version
of
> the UDDI publisherAssertions model and process.

This argument is wearing thin. Nothing stops UDDI from copying our
functionality
instead of cooperating with us.
I did you a courtesy and told you in a private message  that "This is a
generalized version of
the UDDI publisherAssertions model and process". I did that so you could
understand it better. I bet if I had not
you may never have made the connection.

>
>
> I do accept the fact that a generalized approach at associations like this
> may be considered to be a richer capability versus the UDDI
> publisherAssertions ability but I do not see the value in adding this
> complexity into the Oasis ebXML Registry spec.  Maybe the Use Cases and
> requirements that this solution satisfies will convince me otherwise but
> without seeing them clearly listed, my opinions stand.
>

Let try a few more use cases to win you over:

-A dating service registry allows people to register information about them.
It
also allows matchmakers to register and match potential relationships made
in
heaven. Matchmakers can create an extramural Association between any two
peoples
ExtrinsicObject with associationType "suitableFor". Each such Association
should
only be visible to the two people involved and the mach maker.

-User U1 creates a NAICS 1997 scheme. User U2 creates a NAICS 2001 scheme.
User
U3 creates an Associations between the NAICS 1997 and NAICS 2001 saying the
NAICS 2001 supercedes NAICS 1997. Until User U1 and U2 confirm this
association
they do not wish it to be visible to any one besides user U1, U2 and U3.

-An organization O1 claims to be a subsidiary of another Organization O2 by
creating an Association between Orgaizations O1 and O2 with associationType
"subsidiaryOf". This association should not be visible to the rest of the
world
until Organization O2 has confirmed that indeed this is true.



>
> Joel
>
> -----Original Message-----
> From: Farrukh Najmi [mailto:Farrukh.Najmi@Sun.COM]
> Sent: Thursday, November 01, 2001 7:36 PM
> To: regrep@lists.oasis-open.org
> Subject: [regrep] Extramural Associations proposal
>
> Is attached per action item from today. Thanks for your consideration
> given the short lead time.
>
> --
> Regards,
> Farrukh
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC