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?


Lack of UTF-16 support was indeed a conscious decision, but I think we
have to look deeper into the reasoning behind that decision, which is
where I believe the error may be.  I would like to know why the authors
considered it would be most reasonable to decline to support UTF-16,
which appears to have no impact on UDDI service or client
implementation, since UTF-16 support is a requirement of lower-level
infrastructure.  Would we consider erroneous a feature of specification
that was intentional, but poorly or inappropriately motivated?

Again, I do not advocate to run this issue through the errata process
for V2.  This message is for the purpose of exploring what may
constitute an acceptable error within the erratum process framework.


> -----Original Message-----
> From: Arle Lommel [mailto:arle@lisa.org] 
> Sent: Wednesday, October 23, 2002 8:23 PM
> 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 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
> 
> 
> ----------------------------------------------------------------
> 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