RE: ROWS Proposal: please send your recommendation by email

[Scott Hinkelman <srh@us.ibm.com>]

Hi Krishna,

|<soapbox>
|    We should have a vision for the OASIS registry and should add features
|ccording to that vision.
|</soapbox>

I agree: That Vision should materialize as use cases. Perhaps, review of
the current use cases would be in order.

|    Another point re the feature set is Scott's view of "without
significant
|signs of industry traction." IMHO, this is irrelevant as well. If a
feature
|makes sense, include it. None of us have a clear crystal ball to predict
the
|future :o( and adoptability and adaptability.

This was a side comment and not my main concern. I don't necessarily
consider this irrelevant, as what I was indicating is the fact that one of
the approach principals with UDDI from the founding 3 partners was to start
with a defined scope *and then implement it* in a commercial setting, learn
what is needed, then expand scope. The results of that approach are
obvious. To me, I would rather see a TC spec scoped to the fundamental core
use cases so implementations will emerge with feedback, instead of scope
expansion such as Service, Notification, etc.

Scott Hinkelman, Senior Software Engineer
XML Industry Enablement
IBM e-business Standards Strategy
512-823-8097 (TL 793-8097) (Cell: 512-940-0519)
srh@us.ibm.com, Fax: 512-838-1074



"Krishna Sankar" <ksankar@cisco.com> on 09/26/2001 02:58:45 PM

To:   Dan Chang/Santa Teresa/IBM@IBMUS, "'Farrukh Najmi'"
      <Farrukh.Najmi@sun.com>
cc:   Scott Hinkelman/Austin/IBM@IBMUS, "Munter, Joel D"
      <joel.d.munter@intel.com>, "'Lisa Carnahan'"
      <lisa.carnahan@nist.gov>, Tom Glover/Toronto/IBM@IBMCA,
      <regrep-raws@lists.oasis-open.org>
Subject:  RE: ROWS Proposal: please send your recommendation by email



Hi all,

     I have a couple of non-pc observations:

  |
  |   Let's address any perceived deficiencies in UDDI first before we
attempt to
  |   change aspects of the Oasis Registry candidate specifications to
"come
up to
  |   the capabilities" that already  exist in UDDI.  We have several ways
of
  |   requesting changes to the UDDI specifications, 1) through UDDI-WG
member
  |   contributions; 2) through UDDI-AG member contributions 3) through
public
  |   lists; and 4) through the UDDI liaison role.
  |
<KS>
     This OASIS TC not a UDDI TC. Last time I checked, I didn't see the
charter
as "address perceived deficiencies in UDDI". That is work of the UDDI
groups. IMHO, this TC, shouldn't be wasting cycles influencing UDDI, as a
group. I am sure individual members who are in both forums (including
myself) are doing that, anyway .

     Second, one should look at a feature as to whether it makes sense for
an
OASIS Registry. One should not add features because UDDI has it or refrain
from adding a feature because UDDI has that feature. The comparison is
irrelevant. I do not see duplication of features as a cause for concern.

<soapbox>
     We should have a vision for the OASIS registry and should add features
according to that vision.
</soapbox>

     Another point re the feature set is Scott's view of "without
significant
signs of industry traction." IMHO, this is irrelevant as well. If a feature
makes sense, include it. None of us have a clear crystal ball to predict
the
future :o( and adoptability and adaptability.

     I thought there is a sub-group which was going to *position* and
rationalize OASIS registry with UDDI. What is the recommendation of that
group ? Possibly this sub-group could shape the OASIS Registry vision.
</KS>

cheers