OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-rx message

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


Subject: RE: [ws-rx] proposed resolution to i017


Marc,

The reasons you cite for keeping the namespace mutable are not 
inconsistent
with my proposal. However, under my proposal, the namespace *could* be the
final version *as long as the changes we make are backwards compatible* 
and that
*would* allow implementations of earlier drafts of the spec to interop 
with later
versions which would be far more beneficial to the end users than one in 
which
they HAD to rely/wait on the providers of implementations all finally 
aligning on the 
final version.

There is no reason that the "version" component of the namespace match 
that of the
spec itself. None. It's just some value that we assign to allow for the 
namespace URI to 
be differentiate it from other "versions".

Furthermore, the convention you propose is explicitly not in conformance 
with the draft AIR
guidelines as they state that the value should be:

        http://docs.oasis-open.org/[productname]...

The approach you propose would actually be far worse from an interop 
perspective,
not better as you suggest.

All we need to do to prevent interop issues is ensure that any 
non-backwards compatible
changes to the schema/spec result in a *different* namespace URI. Marrying 
the namespace
URI to a dated publication of a draft spec is, IMNSHO, a misguided 
approach, especially
with a schema as relatively straight-forward as the one we have now.

Cheers,

Christopher Ferris
STSM, Emerging e-business Industry Architecture
email: chrisfer@us.ibm.com
blog: http://webpages.charter.net/chrisfer/blog.html
phone: +1 508 377 9295

"Marc Goodner" <mgoodner@microsoft.com> wrote on 08/04/2005 04:05:38 PM:

> I disagree. We should not assign a final namespace now, we should simply
> define the convention to use. Anytime a spec changes that may affect
> conformance or adds a new feature the namespace should change. We can
> not make the determination now that this will be true for the work of
> this TC from now until we reach the point of producing an OASIS
> Standard.
> 
> It is a virtual certainty that products will ship that have support for
> intermediary versions of the spec. If the namespace is constant across
> all of these it will make interoperability in the field much more
> difficult. Each published version of the spec should have its own unique
> namespace. The churn required in code to do this is far less painful
> than the pain customers will feel trying to plug together
> implementations that unbeknownst to them conform to two (or more)
> different versions of the spec. Having a distinct uri for each published
> version of the spec, and subsequently used in products that ship with
> support for those versions, helps greatly in preventing this.
> 
> I do agree we do not need to resolve i015 before determining the form of
> the namespace on the same grounds that you do below.
> 
> I propose the following resolution to i017[1]:
> 
> The namespace URI used for our specs should follow the draft AIR
> Guidelines as follows:
> http://docs.oasis-open.org/yyyy/mm/[productname]
> Where [productname] is the name from the resolution of issue i015 [2]
> for the respective specs and yyyy/mm is the date of the published
> version of the specification.
> 
> [1]
> http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/13809/Re
> liableMessagingIssues.xml#i017 
> 
> [2]
> http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/13809/Re
> liableMessagingIssues.xml#i015 
> 
> -----Original Message-----
> From: Christopher B Ferris [mailto:chrisfer@us.ibm.com] 
> Sent: Wednesday, August 03, 2005 7:52 AM
> To: ws-rx@lists.oasis-open.org
> Subject: [ws-rx] proposed resolution to i017
> 
> All,
> 
> I propose that we resolve issue i017 [1] as follows:
> 
> The namespace URI used for our specs should follow the draft AIR 
> guidelines. e.g.
> 
> http://docs.oasis-open.org/[productname]1
> 
> where [productname] is whatever we conclude for issue i015 [2] for the 
> respective specs. The trailing '1'
> signifies the "version" of the *namespace* but is NOT in any way tied to
> 
> the version/revision of the corresponding
> schema for that namespace (see my previous rants on this subject). This 
> will allow us to assign a final namespace
> URI for the specifications that we are chartered to produce (rather than
> 
> having to either guess at a date, or worse
> yet, change the namespace name with each successive published draft -- 
> BLECH!)
> 
> I would also assert that we do not need to resolve i015 before resolving
> 
> that the form of the namespace
> URI will be as above... we just fill in the blank once we have settled
> on 
> a [productname] for our specs.
> 
> Benefits: this yields a nice SHORT namespace URI (see my previous rants)
> 
> it allows us to assign a final URI
> now, rather than waiting until we are essentially done (good for 
> implementation as it reduces unnecessary churn
> to tweak the namespace URI in code).
> 
> [1] 
> http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/13809/Re
> liableMessagingIssues.xml#i017
> [2] 
> http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/13809/Re
> liableMessagingIssues.xml#i015
> 
> Cheers,
> 
> Christopher Ferris
> STSM, Emerging e-business Industry Architecture
> email: chrisfer@us.ibm.com
> blog: http://webpages.charter.net/chrisfer/blog.html
> phone: +1 508 377 9295



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