Next in thread →
Next in month →
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
> > 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 <> wrote on 17/12/2014 13:33:39: > From: Steve K Speicher <> > To: "OASIS OSLC Core TC Discussion List" <> > 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: <> > > Martin P Pain <> wrote on 12/17/2014 07:49:33 AM: > > > From: Martin P Pain <> > > To: Steve K Speicher/Raleigh/IBM@IBMUS > > Cc: "OASIS OSLC Core TC Discussion List" > <> > > 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 > > > > > > <> 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 > > > --------------------------------------------------------------------- > 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
Next in thread →
Next in month →