← Prev in month ← Prev in thread

Shapes that don't change across versions, multiple shapes per resource type & cheap changes. Re: [oslc-core] Conventions around publication of "resource shapes" from TCs

From
Martin P Pain <>
Date
2014-12-17T16:04:29+00:00
ID
Thread
Shapes that don't change across versions, multiple shapes per resource type & cheap changes. Re: [oslc-core] Conventions around publication of "resource shapes" from TCs
1.

If in future we produce a new version
of the spec (e.g. "3.1") which changes some shapes but not others,
would you imagine having a redirect from the /3.1/ URL to the /3.0/ one
for those that haven't changed, or just have the spec reference a mixture
of /3.0/ and /3.1/ URLs?

2.

Some resource types may have more than
one shape - e.g. one minimal shape for creation, and another for retrieval
that includes properties that are only expected to be set by the server.

For those cases we might want:

http://open-services.net/ns/<vocab
short name>/shapes/<version>/<resource-type>/<shape-name>

or:

http://open-services.net/ns/<vocab
short name>/shapes/<version>/<resource-type>#<shape-name>

but I think this is compatible with
your existing proposal.

3.

Also, apart from correcting typos, etc,
are there any changes that would go into a shape in a subsequent version
of the spec without increasing the version number (other than fixing typos,
etc)? e.g. if at v3 any spec/profile still requires providers to not generate
an error if they receive a property with which they are unfamiliar, would
adding a new property in a shape be a 'cheap' change that wouldn't require
a new version?

I presume we won't make any material
changes without increasing the version number, but I think it's worth discussing
briefly now.

Martin

<> wrote on 16/12/2014
17:26:24:

> From: Steve K Speicher <>

> To: "OASIS OSLC Core TC Discussion List"
<>

> Date: 16/12/2014 17:26

> Subject: [oslc-core] Conventions around publication
of "resource 

> shapes" from TCs

> Sent by: <>

> 

> As we've covered already is the usage and handling of vocabulary (RDF

> schema) to be hosted at a namespace starting with "

> http://open-services.net/ns/*"
[1], we didn't conclude how shapes were to 

> be handled.

> 

> Shapes are different than vocabularies in that shapes may change with
new 

> revisions of resource definitions.  Vocabularies will evolve
in place.

> Though they are the same in that they are both described in RDF and
we'd 

> like a Cool URIs [2] for them.

> 

> So I propose this pattern:

> 

>         http://open-services.net/ns/<vocab
short 

> name>/shapes/<version>/<shape-name>

> 

> For example, for Change Management 3.0 it would have:

> 

>         http://open-services.net/ns/cm/shapes/3.0/changerequest

> 

> Unless there are any objections or someone sees an adjustment we need
to 

> make to this, I will proceed with this approach.

> 

> [1]: 

> https://www.oasis-open.org/apps/org/workgroup/oslc-core/email/

> archives/201409/msg00022.html

> [2]: http://www.w3.org/TR/cooluris/

> 

> Thanks,

> Steve Speicher

> IBM Rational Software

> OSLC - Lifecycle integration inspired by the web -> 

> http://open-services.net

> 

> 

> ---------------------------------------------------------------------

> To unsubscribe from this mail list, you must leave the OASIS TC that

> generates this mail.  Follow this link to all your TCs in OASIS
at:

> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

> 

Unless stated otherwise above:

IBM United Kingdom Limited - Registered in England and Wales with number
741598. 

Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU
← Prev in month ← Prev in thread