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] Comments on future intentions for V3

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


Sorry, if I should have said this at the face-to-face today and didn't. But it is my opinion that when UDDI.org turned V3 over to OASIS it did so with the intent that V3 was a completed specification that needed implementation and blessing as an OASIS Specification. Of course ERRATA are a normal maintenance function...but ENHANCEMENT is not.

I agreed to  blur this distinction with the addition of UTF-16 support to V3, but few items on the long list we built this afternoon are appropriate additions to V3; rather they are considerations for a possible UDDI V4.

Am I the only one confused by this discussion???

Mike DeNicola

> -----Original Message-----
> From: William Cox [mailto:william.cox@bea.com]
> Sent: Tuesday, November 12, 2002 9:31 AM
> 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."

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC