Re: [uddi-spec] Erratum an error?

[Alok Srivastava <Alok.Z.Srivastava@oracle.com>]

Tom,

Thanks for clarification. I guess I should have said that v3 is not yet
voted for Standard submission process. I understand that we are not making a
change in v2 and that is ok if everyone else agrees with it. Errata or Spec
change is not my concern from the implementation perspective, whatever
happens to be the majority consideration will work as long as the
specification at the end includes the desired changes. Since Claus has
suggested that he is going to submit Spec Change request, all I wanted to
know if that is possible at the current state of v3. From your response it
is clear that it is possible to consider this request for v3 based upon the
spec as it stands today. please correct me if I am wrong in my assumptions.

Personally I would like to see this issue resolved soon in such a way that
there is no conflict with WS-I recommendations (when they are released). In
case of a conflict with WS-I recommendations, we will either be UDDIv2
compliant or WS-I compliant not both. I am hoping for a reasonable
resolution with WS-I, all I can add to the discussion that has already taken
place, is that from implementation perspective this is really a non-issue or
a minor issue at best.

Thanks,
Alok
----- Original Message -----
From: "Tom Bellwood" <bellwood@us.ibm.com>
To: "Alok Srivastava" <Alok.Z.Srivastava@oracle.com>;
<uddi-spec@lists.oasis-open.org>
Sent: Thursday, October 24, 2002 10:52 AM
Subject: Re: [uddi-spec] Erratum an error?


|
|
|
|
| Alok,
|
| If you will consult the minutes from our first meeting, we did indeed
| approve V2 and V3 as OASIS Specifications.  We also approved V2 to enter
| the Standards submission process.   That said, it's neither here not
there,
| as they say.  We still have the ability at any time to update a
| specification with errata.   We decided on our last call not to make
| changes to V2 for this issue.  We also decided to consider a change to V3,
| for which Claus is creating a document for the TC's consideration.
Whether
| or not this change can be considered errata to the spec. is a matter for
| debate, although I'm sure reasonable arguments can be made in either
| direction.  In the end, I think it probably boils down to what we
| collectively feel is best for UDDI and the industry.
|
| Thanks,
| Tom Bellwood
|
|
| Alok Srivastava <Alok.Z.Srivastava@oracle.com> on 10/24/2002 09:04:23 AM
|
| To:    "Von Riegen, Claus" <claus.von.riegen@sap.com>, "'Arle Lommel'"
|        <arle@lisa.org>, uddi-spec <uddi-spec@lists.oasis-open.org>
| cc:
| Subject:    Re: [uddi-spec] Erratum an error?
|
|
|
| Claus,
|
| Version 2 or version 3 are not approved OASIS specs yet. We have voted for
| version 2 to be OASIS spec but I don't think version 3 has been voted yet.
| Can we proceed with change request without having an approved spec?
|
| Thanks,
| Alok
| ----- Original Message -----
| From: "Von Riegen, Claus" <claus.von.riegen@sap.com>
| To: "'Arle Lommel'" <arle@lisa.org>; "uddi-spec"
| <uddi-spec@lists.oasis-open.org>
| Sent: Thursday, October 24, 2002 3:50 AM
| Subject: RE: [uddi-spec] Erratum an error?
|
|
| | Arle,
| |
| | Later in our conference call, there was a vote on the proposal to drop
| the
| idea of introducing UTF-16 support in UDDI Verions 2. There were no
| objections, which means that we do not plan to introduce UTF-16 to UDDI
| Version 2 any longer.
| |
| | In order to discuss the consequences for UTF-16 support in UDDI Version
| 3,
| I will create a specification change request and distribute it before the
| F2F in Philadelphia.
| |
| | Best regards,
| |  Claus
| |
| | -----Original Message-----
| | From: Arle Lommel [mailto:arle@lisa.org]
| | Sent: Mittwoch, 23. Oktober 2002 18:23
| | To: uddi-spec
| | Subject: [uddi-spec] Erratum an error?
| |
| |
| | I would defer to the judgment of others as to whether UTF-16 support
| should
| | be added into previous versions of UDDI (it doesn't affect me directly
as
| we
| | aren't implementing UDDI at this time), but I really feel that the
errata
| | process is not the way to handle this. Lack of UTF-16 support was a
| | conscious decision, not an inadvertent oversight or mistake. The errata
| | process is not to be used to introduce new functionality to a standard,
| but
| | if this is dealt with as an erratum we would be using the process do
what
| it
| | is *explicitly* not supposed to do (unless I have grossly misunderstood
| the
| | document describing the process). Or is adding UTF-16 support not new
| | functionality? (If it isn't I would like a clear explanation of what
does
| or
| | does not constitute new functionality.)
| |
| | Perhaps this was discussed in the conference call yesterday - I had to
| dro
| p
| | out after about 45 minutes, at which point the conversation was still on
| | UTF-16 support, but it had not broached the topic of how to handle it.
If
| in
| | the call someone made a convincing argument that this issue should be
| | handled through an erratum, I would like to hear it (and I am open to
| | persuasion), but right now if put to a vote to approve this as an
erratum
| I
| | would vote in the contrary since I don't feel it's the right way to
| handle
| | this. (Perhaps this came to a vote during the call, in which case I am
| too
| | late to voice any opposition. When do the minutes come out?)
| |
| | Since everyone in the group seems to see this as a more or less major
| issue,
| | I would expect that implementers would similarly see it as a more or
less
| | major issue. If I were an implementer and faced with an erratum that
| | mandated a major change, I would really wonder about the stability of
| UDDI
| | and about what the UDDI group is doing. This isn't the same sort of
thing
| as
| | saying that we inadvertently specified an incorrect tag name somewhere
| and
| | we need to fix it (a very proper use of the errata process).
| |
| | The fact is that adding in a requirement for UTF-16 support would mean
| that
| | an implementation that today conforms entirely to UDDI 2.0 could find
| that
| | tomorrow it won't work with half the queries it receives and that it is
| no
| | longer UDDI 2.0 compliant. This would be akin to switching half of the
| | gas/petrol stations in the world to compressed methane instead of
| | gasoline/petrol, saying it was an inadvertent oversight that we ever
told
| | motorists to use only gasoline, and telling car owners that it's their
| job
| | to comply since they are not now complying with the requirements of the
| | motoring world. (This is an exaggeration, of course, but it makes the
| | point.)
| |
| | That said, I don't have any problem at all with somehow
| | adding/patching/fixing/(pick an appropriate verb) UDDI 2.0 or 3.0, if
| that
| | is deemed necessary. We should do what makes the standard work for
| people.
| | But if we went through the trouble of setting up a process for how work
| | should precede, then we really ought to follow what we voted to accept.
I
| | understand the desire of those who just want to fix the situation, but
| let's
| | do it right.
| |
| | I previously had suggested making a UDDI version 2.1, that would in all
| | respects be identical to 2.0, except for adding what is needed to meet
| the
| | WS-I requirements in this matter. This idea was rejected (on good
grounds
| I
| | think), but the fact that having a 2.1 is not desirable does not
| conversely
| | make use of the errata process in this manner desirable. I don't know
| what
| | the solution is. Perhaps those wiser than I can see their way clear of
| this.
| |
| | -Arle Lommel
| | LISA
| |
| |
| | ----------------------------------------------------------------
| | To subscribe or unsubscribe from this elist use the subscription
| | manager: <http://lists.oasis-open.org/ob/adm.pl>
| |
| | ----------------------------------------------------------------
| | To subscribe or unsubscribe from this elist use the subscription
| | manager: <http://lists.oasis-open.org/ob/adm.pl>
| |
|
|
| ----------------------------------------------------------------
| To subscribe or unsubscribe from this elist use the subscription
|  manager: <http://lists.oasis-open.org/ob/adm.pl>
|
|
|