[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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> 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]