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

[Matthew Dovey <matthew.dovey@las.ox.ac.uk>]

OK, I'm not at the meeting so don't know what was discussed/is being
discussed but I'll outline my current understanding (or at least
understanding before the FTF).

According to the OASIS process we need "certification by at least three
OASIS member organizations that they are successfully using the
specification consistently with the OASIS IPR Policy" before a committee
spec can become an OASIS standard. Whilst there is work on v3
implementations in progress, I don't think we're at that point at the
moment. Hence v3 is only at the committee spec. stage. It was my
recollection that this was the main reason for not taking both v2 and v3
to OASIS specs at the first meeting.

I would regard that as v3 is at the committee spec stage it is fairly
fixed as a standard. That said it isn't immune to specification changes
and/or errata in the same sense that v2 isn't immune even though this is
going forward as an OASIS standard (and even after it has gone through
this process successfully). As such what goes forward as an OASIS
standard may be 3.0x, and maybe updated subsequently to 3.0y.

However, errata and change requests are different from new feature
requests (UTF-16 support for example is really a spec change rather than
a new feature). New features discussion as opposed to fixing v3 features
is for the v4 discussion.

Matthew



> -----Original Message-----
> From: William Cox [mailto:william.cox@bea.com] 
> Sent: 12 November 2002 16:31
> To: UDDI Spec List
> Subject: [uddi-spec] Comments on future intentions for V3
> 
> 
> 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."
> 
> 
>