RE: [oslc-promcode] Re: Including files in specifications for PROMCODE

[Kazuhiro Funakoshi <k-f@bk.jp.nec.com>]

Hi Robin,

Thank you for your quick reply. I think now I understand.

In my question, actually my intention was when lifecycle in OASIS TC and vocabulary documents is synchronized. However, you answer is in more general case, so it is fine.

> If the TC wants to use a namespace name URI for a spec 
> that applies to more than one Version of the specification 
> (e.g., http://open-> services.net/ns/promcode# ) -- that should be OK as far as I know.

So our TC can also decide to add version for the path, and the great thing is, we can decide when we want to publish next version not only at the first version.

Thank you very much.

-- 
Kaz


From: oslc-promcode@lists.oasis-open.org [mailto:oslc-promcode@lists.oasis-open.org] On Behalf Of Robin Cover
Sent: Wednesday, December 17, 2014 11:00 AM
To: Funakoshi Kazuhiro(船越 和大)
Cc: Arthur Ryman; oslc-promcode@lists.oasis-open.org; Steve K Speicher; Robin Cover
Subject: Re: [oslc-promcode] Re: Including files in specifications for PROMCODE

Re:

> Hi Robin,
> 
> (2) above also has been discussed, right?
> Is it a correct behavior that v1.0 shapes refer to v2.0 or newer vocabulary?

Kaz,

Your question in the context of this thread seems to relate to the notion of "Version" with respect to the OASIS identifier schemes -- and not to vocabulary "versions" under a (different) open-services.net versioning scheme ... right?  Assuming that you mean OASIS "Version", I'll try to clarify how we use namespace name identifiers and versioning

* Version: http://docs.oasis-open.org/specGuidelines/ndr/namingDirectives.html#Version

A "Version" is identified with a unique Work Product, used in all releases for the specification lifecycle for that Work Product ( WD, CSD, CS, COS, OS).  Once the Work Product comes to CS or OS (OASIS Standard) level (or is abandoned), that "Version" is complete.

While a Work Product is progressed through its lifecycle, namespace name identifiers can also be revisioned (e.g., incremented using numeric components in sequence), per the wishes of the TC

The Naming Directives document clarifies that for namespace URIs using the docs.oasis-open.org domain ( pattern: http://docs.oasis-open.org/[tc-shortname]/ns/xxxx ), the final "xxxx" should ( should, not must) "incorporate a versioning subcomponent (e.g., a string like 201011 representing a date or v1.1 representing a version number)".  In the case of the OSLC specs, where legacy namespace name URIs and construction patterns are being used, the OASIS guidance about "versioning subcomponent" is not directly applicable

If the TC wants to use a namespace name URI for a spec that applies to more than one Version of the specification  (e.g., http://open-services.net/ns/promcode# ) -- that should be OK as far as I know.  Whatever URI aliasing machinery is set up to deliver the correct representation from the OASIS server when the "open-services.net" URI reference is dereferenced -- should fetch/deliver whatever the TC elects.  In the case of traditional OASIS specs, namespace name URIs have often been versioned (per Naming Directives "should") in support of a TC's goals for implementation, conformance, etc.  But if you don't want to (verbatim) version your namespace names, I think that's up to you, per SemWeb expectations

Irrespective of the above, the use of "Latest version:" URIs is scoped to a particular OASIS "Version".  That's orthogonal to the conventions your TC may want to use in versioning or nor versioning a namespace name URI

How OASIS "Latest version:" URIs work in the case of "Versions": the KMIP Profiles will illustrate the point: "Latest" is bound to one Version, and does not cross Versions

http://docs.oasis-open.org/kmip/profiles/
http://docs.oasis-open.org/kmip/profiles/v1.0/
http://docs.oasis-open.org/kmip/profiles/v1.1/
http://docs.oasis-open.org/kmip/profiles/v1.2/

A couple more clarifications below:


On Tue, Dec 16, 2014 at 7:05 PM, Kazuhiro Funakoshi <k-f@bk.jp.nec.com> wrote:
Arthur,

Thank you for information.
I will change current our shape document as you told me.

(1)
However, the following lines seems not correct, does it?

>
http://docs.oasis-open.org/oslc-promcode/projectshape/v1.0/projectshape.rdf
>
http://docs.oasis-open.org/oslc-promcode/projectshape/v1.0/projectshape.ttl
>
http://docs.oasis-open.org/oslc-promcode/projectshape/v1.0/projectshape.html

In the case of a Work Product "projectshape", we expect for the version-specific (per release) identifiers:

[Release]
http://docs.oasis-open.org/oslc-promcode/projectshape/v1.0/csd01/projectshape-v1.0-csd01.html

Latest:
http://docs.oasis-open.org/oslc-promcode/projectshape/v1.0/projectshape-v1.0.html

per:
http://docs.oasis-open.org/specGuidelines/ndr/namingDirectives.html#paths
http://docs.oasis-open.org/[tc-shortname]/[WP-abbrev]/[version-id]/[stage-abbrev][revisionNumber]/[doc-id].[ext]


Hope that helps.  If not, or if I messed up something (on too little sleep), please let me know.

- Robin

 
They should be:

>
http://docs.oasis-open.org/oslc-promcode/projectshape/v1.0/{Artifact,WorkIte
m,ScopeItem,Issue,etc}.{rdf,ttl}
>
http://docs.oasis-open.org/oslc-promcode/projectshape/v1.0/projectshape.html

I will change our shape document in WebSVN as once they are approved, then
we can simply copy from WebSVN to docs.oasis-open.org.

(2)
When we have v2.0, if we use [1] as stable @prefix for v1.0 shape document
it will means v1.0 shape documents uses v2.0 vocabulary document, because
[1] redirect to v2.0 vocabulary document.
I understand we will never change existing v1.0 content but only extend as
v2.0, still confusing.
This wouldn't happen for shape document because it seems not have stable
redirect URL between major versions as you said:

> The shape document for Project resources will be:
> http://open-services.net/ns/promocode/shapes/1.0/project

Is my understanding correct?

[1] http://open-services.net/ns/promcode#


Hi Robin,

(2) above also has been discussed, right?
Is it a correct behavior that v1.0 shapes refer to v2.0 or newer vocabulary?

--
Kaz

Attachment: smime.p7s
Description: S/MIME cryptographic signature