uddi-spec message

Subject: [uddi-spec] Comments on future intentions for V3

From: William Cox <william.cox@bea.com>
To: UDDI Spec List <uddi-spec@lists.oasis-open.org>
Date: Tue, 12 Nov 2002 11:31:22 -0500

This is a followup to my comments and discussion in the F2F Monday
morning, and is written in part by my "outer pedant" [apologies to Tony
Rogers].

I believe that the group clarified the situation by saying  (via Luc)
that "V3" [see note below] is the basis for current work, and that "V4"
is a vague future version that is completely undefined.  Current work
will take what I think of as "Version 3.0000" and modifiy/evolve it as
change requests are accepted by the groujp, leading to a sequence of
editor's versions with version numbers like 3.02, 3.05, etc.

If this is the case, it directly contradicts the minutes for the 13
September 2002 meeting quoted below, which suggests the freezing of the
documents approved as OASIS Committee Specifications and defining future
work as V4.

Note: Since the TC accepted "V3" with specific documents as an OASIS
Committee Specification, we have created a separate time series for
OASIS Committee Specifications.  Since these are generally used in OASIS
as a kind of "clean point" that are viewed by the committee as complete
and ready for detailed analysis/review/implementation, perhaps we made a
mistake is so designating "V3" at the first meeting.  We are also
confusing ourselves by talking about "V3" as a fixed thing -- it is, as
a CSpec, but it's also been used in discussions as a family of specs
evolving via change requests.

Are we misleading others who think that the TC thinks that the "V3" on
the web site is complete and ready for implementation (subject only to
minor bugs)?

I suggest putting a note on the TC web page stating something like "the
next "V3 family" Committee Specification is planned for early 2003 after
dealing with change requests from the review and implementation
process." This should probably be identified as OASIS Committee
Specification version 3.1.

bill cox


Background information:

The minutes for the initial meeting on 13 September 2002 said:

"Specification Baseline Motion: A motion to establish the UDDI V3
Committee Specification as the TC’s baseline for all future work was
presented. Debate on this issue occurred which mostly centered on why we
are not trying to take the V3 work forward as an OASIS Standard. There
was general agreement that companies needed more experience with the V3
specification before this would be appropriate and the TC agreed to
review this in several months time. Further discussion was ruled as out
of order to the motion at hand. A question was raised by Alok on whether
the intention was the future work would then become a V4, or be added
into V3. This was clarified by the chairs and several members of the TC
that this would constitute work on a V4.
An individual vote was taken and the resolution passed. There was no
dissent."

Minutes from 22 October 2002 said (in passing):

"4.2.4 Prioritize work on legacy TN’s (1, 2 or 3) and request chairs to
drive the high priority ones."  [I'm not clear on whether this is TNs
for UDDI v1, v2, and v3, or something else.]

Matthew Dovey (in Tony Rogers' "inner pedant email" attached) wrote:

"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)."

And Tony wrote:

"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."

Date: Fri, 25 Oct 2002 09:04:26 -0500
From: Tom Bellwood <bellwood@us.ibm.com>
Subject: Re: [uddi-spec] Erratum an error?
To: karl.best@oasis-open.org, uddi-spec@lists.oasis-open.org
Message-id: <OF59403E03.ED4D9A83-ON86256C5D.004CFEB9@us.ibm.com>
MIME-version: 1.0
Content-type: text/plain; charset=US-ASCII
Importance: Normal
Sensitivity: 

Hi Karl,

Yes.  I thought I had clearly stated that a couple of notes ago, but just
to avoid any ambiguity.

1)  UDDI V2 IS an APPROVED TC Specification
2)  UDDI V3 IS an APPROVED TC Specification
3)  UDDI V2 IS APPROVED to go forward in the Standards Submission process.
Luc and I are currently preparing the package for that

Anyone who was present at our first meeting, or who reads the minutes of
that meeting is well aware of these facts.

Thanks,
Tom Bellwood
Co-Chair, OASIS UDDI Specification TC

Karl Best <karl.best@oasis-open.org> on 10/25/2002 08:38:59 AM

Please respond to karl.best@oasis-open.org

To:    uddi-spec@lists.oasis-open.org
cc:
Subject:    Re: [uddi-spec] Erratum an error?

I can't follow all this discussion about "OASIS Specifications" and
"Committee Drafts" etc. Let's get the terminology straight. There are
two levels of approval defined in the OASIS TC Process:

- Committee Specification (approved by the TC)
- OASIS Standard (approved by the OASIS membership)

The process for each of these is defined in
http://www.oasis-open.org/committees/process.shtml#standards_process

Luc/Tom: Are UDDI v2 and v3 both approved by the TC as Committee Specs?

-Karl

=================================================================
Karl F. Best
OASIS - Director, Technical Operations
+1 978.667.5115 x206
karl.best@oasis-open.org  http://www.oasis-open.org

----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
 manager: <http://lists.oasis-open.org/ob/adm.pl>

----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>

Content-return: allowed
Date: Wed, 16 Oct 2002 09:47:02 +1000
From: "Rogers, Tony" <Tony.Rogers@ca.com>
Subject: RE: [uddi-spec] Issue u11: UDDI mandates UTF-8
To: UDDI list <uddi-spec@lists.oasis-open.org>
Message-id: <4EF4335BEA233049856A7EB9D2BD115479A52F@aspams03>
MIME-version: 1.0
Content-type: text/plain

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>

----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>

Attachment: william.cox.vcf
Description: Card for William Cox