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

[Steve K Speicher <sspeiche@us.ibm.com>]

Martin P Pain <martinpain@uk.ibm.com> wrote on 12/17/2014 07:49:33 AM:

> From: Martin P Pain <martinpain@uk.ibm.com>
> To: Steve K Speicher/Raleigh/IBM@IBMUS
> Cc: "OASIS OSLC Core TC Discussion List" 
<oslc-core@lists.oasis-open.org>
> Date: 12/17/2014 07:49 AM
> Subject: 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? 
> 
I would think that we'd republish at the "latest" version, that way anyone 
picking up the spec from a given time doesn't have to flatten all the 
versions to get the "latest".

Though I don't have a strong preference.  I could see where publishing a 
shape at the new URI when nothing has changed to be a bit confusing as 
well.

> 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. 
> 
Agree it is within the current naming approach but we should follow a 
similar pattern/approach.

> 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. 
>
I would think that the only time to add, and not bump the version number, 
is when the spec is still evolving (frozen at Committee Specification). 
Adding a new optional property after this seems like it would require a 
bump in the version number. Are you saying this approach may be too rigid 
for some scenarios you have?

The idea would be that shapes could build off of shapes, ie a locally 
installed and configured instance may add customer-defined 
properties...therefore a tool-specific shape.

- Steve

 
> Martin
> 
> 
> <oslc-core@lists.oasis-open.org> wrote on 16/12/2014 17:26:24:
> 
> > From: Steve K Speicher <sspeiche@us.ibm.com> 
> > To: "OASIS OSLC Core TC Discussion List" 
<oslc-core@lists.oasis-open.org> 
> > Date: 16/12/2014 17:26 
> > Subject: [oslc-core] Conventions around publication of "resource 
> > shapes" from TCs 
> > Sent by: <oslc-core@lists.oasis-open.org> 
> > 
> > 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