[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [uddi-spec] Issue u11: UDDI mandates UTF-8
On the "UDDI V3 as basis for future work" issue, my inner pedant insists on pointing out that the agreement was that any future work was to result in a UDDI V4, rather than an altered V3. While the idea of a V2.1 is initially attractive, it introduces even more testing: Server Client V2 (UTF-8) with V2 (UTF-8) V2 (UTF-8) with V2.1 (UTF-8) V2.1 (UTF-8) with V2 (UTF-8) V2.1 (UTF-8) with V2.1 (UTF-8) V2.1 (UTF-8) with V2.1 (UTF-16) V2.1 (UTF-16) with V2.1 (UTF-8) V2.1 (UTF-16) with V2.1 (UTF-16) Plus a case I'd expect to see fail: V2.1 client talking UTF-16 to V2 server (server probably wouldn't understand). Plus an "interesting" case: V2 client talking UTF-8 to a V2.1 server - the server would have to respond in UTF-8, for obvious reasons. Looking at all of that, my inclination is to run away! :-) I urge that we drop the idea of including UTF-16 in V2, at least, and give serious thought to the idea of not including it in V3. Tony Rogers Computer Associates Tony.rogers@ca.com -----Original Message----- From: Matthew Dovey [mailto:matthew.dovey@las.ox.ac.uk] Sent: Wednesday, 16 October 2002 1:15 To: Arle Lommel; UDDI list Subject: RE: [uddi-spec] Issue u11: UDDI mandates UTF-8 > Although it was agreed in the first phone meeting that > version 3 would serve as the basis for all further work, if > it were it agreed that version 2 needed "fixing" for purposes > of UTF-16 support, and that an erratum is not the proper way > of addressing the issue, would it be possible to issue a > version 2.1 specifically for this purpose, and which would be > identical to version 2, except for support for UTF-16? I think at the first meeting this issue was discussed I suggested that this was probably a Specification Change request i.e. dealt with under the process described in 1.6 of the process document rather than an erratum per se - i.e. it could be construed as feedback from implementers tackling WSI conformance. This way we can avoid the argument of whether not adopting UTF-8 was accidental or deliberate (it was clearly the latter from the discussion) and concentrate on whether we want to adopt UTF-16. As I see it there are two fundamental questions to address: i) do we want UDDI to adopt UTF-16 or stick with UTF-8? (this rests on consensus of supporting UTF-16 per se) ii) if we do adopt UTF-16 is this a specification change request for v2 and v3 or just v3. (This rests on the implementation impact on existing v2 software). In any case, I believe it was agreed that whenever a set of erratum and/or specification changes are published (and it was suggested we batch these so not to appear to be changing the standard too often), this would result in a minor version increment for UDDI (v2 is already at v2.07 or there abouts) - also that the version numbers of all the v2 documents (API, Data Structures etc) should be kept in sync (even if these means that the a document is reissued without any other change but the version number). Matthew ---------------------------------------------------------------- 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