oslc-core message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: 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
- From: Martin P Pain <martinpain@uk.ibm.com>
- To: Steve K Speicher <sspeiche@us.ibm.com>
- Date: Thu, 18 Dec 2014 14:46:16 +0000
> > 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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]