RE: [ws-rx] proposed resolution to i017

["Marc Goodner" <mgoodner@microsoft.com>]

I agree we are actually fairly close in our proposals. If each published
version of the spec is backward compatible with the last I am much more
sympathetic to keeping the namespace the same. However each publication
should be reviewed to determine if that is true. 

In order to be more consistent with the AIR guidelines I will move to
modify my proposal to have the form of the namespace have a trailing
date rather than leading as follows:
http://docs.oasis-open.org/[productname]/yyyy/mm/ 

I do note that both this proposal and my original are consistent with
the AIR guidelines. There is no provision for the form of a namespace
url there, only that it resolves to a RDDL document on an OASIS server.
Your original proposal and my revised proposal above are both more
consistent with the persistent url guidelines in section 7, however
those guidelines are for specific artifacts and are not referred to by
the namespace requirements in section 6.2. Similarly there is nothing in
the AIR guidelines that support adding trailing indicators to the
persistent url for a namespace url, an artifact, or any other purpose.

Now all of that said I think this should be used as input to the TAB
regarding the requirements for namespaces and the use of persistent
urls. It would be nice if the answer simply came from the AIR guidelines
so we could refer to it in this and future work.

Regards,
Marc g

-----Original Message-----
From: Christopher B Ferris [mailto:chrisfer@us.ibm.com] 
Sent: Friday, August 05, 2005 8:12 AM
To: Marc Goodner
Cc: ws-rx@lists.oasis-open.org
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