Re: [regrep] Extramural Associations proposal

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

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>
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