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


Okay, but then IMO, we should collapse the yyyy/mm to yyyymm as there's no 
need to create
a heirarchy. 

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/11/2005 03:02:30 PM:

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



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