[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
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> |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC