OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

uddi-spec message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


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>

Attachment: William.Cox.vcf
Description: Card for William Cox



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC