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] 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