Re: [uddi-spec] Erratum an error?

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

Luc/Tim,

Just a process question. I remember our discussion on what happens when the
change requests (or errata) are approved, do we create a new version of the
spec (like 3.1)? Has there been any agreement on this? The uddi-tc-spec
document does not seem to talk about this. Perhaps I missed something.

Thanks,
Alok
----- Original Message -----
From: "William Cox" <William.Cox@bea.com>
To: "Alok Srivastava" <Alok.Z.Srivastava@oracle.com>
Cc: "Von Riegen, Claus" <claus.von.riegen@sap.com>; "'Arle Lommel'"
<arle@lisa.org>; "uddi-spec" <uddi-spec@lists.oasis-open.org>
Sent: Thursday, October 24, 2002 10:37 AM
Subject: Re: [uddi-spec] Erratum an error?


| The real issue is the progress of v2; at the first meeting of this OASIS
TC it
| was voted to be a Committe Draft with the intent to move it toward OASIS
| Standard.  I don't know whether that step has been taken for v2, but a
| substantive change will start that process over again. It speaks ill of
the
| stability intended for OASIS Committee Specifications to move these
forward and
| then make such changes.
|
| The group decided that v3 would not move to OASIS standard, but that the
next
| version would; v2 was the stable, in the field version.
|
| I would prefer to not change in any way v2 as in the field.
|
| bill cox
|
| Per the minutes:
|
| V2 Specification Resolution:  A resolution was made to adopt the UDDI
Working
| Group V2 specification contributions as OASIS UDDI Spec TC UDDI V2
Committee
| Specifications.
|
| V3 Specification Resolution:  A resolution was made to adopt the UDDI
Working
| Group V3 and Schema Centric Canonicalization specification contributions
as the
| OASIS UDDI Spec TC UDDI V3 Committee Specification and the Schema Centric
| Canonicalization Committee Specification respectively.
|
| V2 Standard Resolution:  A resolution to approve the OASIS UDDI V2
| Specifications for submission to OASIS vote as an OASIS Standard was
presented.
|
| All three of these motions passed without dissent.
|
|
|
|
| Alok Srivastava wrote:
|
| > 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>
|