Re: [uddi-spec] Erratum an error?

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

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