[uddi-spec] Erratum an error?

[Arle Lommel <arle@lisa.org>]

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