Re: [oslc-core] 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

[Martin P Pain <martinpain@uk.ibm.com>]

> > 2. 
...
> Agree it is within the current naming approach
but we should follow a 
> similar pattern/approach.

Do you mean all groups should use either
the one with resource type or the one without? 

> > 3.
...
> Are you saying this approach may be too rigid
> for some scenarios you have?

No, I was just aware that there were
2 choices. and we hadn't been explicit.

Martin

<oslc-core@lists.oasis-open.org> wrote on 17/12/2014
13:33:39:

> From: Steve K Speicher <sspeiche@us.ibm.com>
> To: "OASIS OSLC Core TC Discussion List"
<oslc-core@lists.oasis-open.org>
> Date: 17/12/2014 21:42
> Subject: [oslc-core] 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
> Sent by: <oslc-core@lists.oasis-open.org>
> 
> 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
> 
> 
> ---------------------------------------------------------------------
> 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