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