[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [oslc-core] Motivation and proposal for oslc:archive property
On Wed, Nov 12, 2014 at 3:03 PM, Steve K Speicher <sspeiche@us.ibm.com> wrote:
Hey Samit,
I would think it would make sense, I assume you do if you are asking the questions. So the guidance you are suggesting is something along the lines of: by default, archived resources are excluded...a client would have to explicitly request them. I guess this would be implied in dialogs as well but might be good to be explicit. I could expect the dialogs (and other scenarios) to be heavily dependent on the context that they are being used: for example if there is an archived resource selection dialog...you would expect to see only the archived resources.
Thanks,
Steve Speicher
IBM Rational Software
OSLC - Lifecycle integration inspired by the web -> http://open-services.net
From: Samit Mehta/San Francisco/IBM@IBMUS
To: Steve K Speicher/Raleigh/IBM@IBMUS
Cc: "OASIS OSLC Core TC Discussion List" <oslc-core@lists.oasis-open.org>, oslc-core@lists.oasis-open.org
Date: 10/02/2014 01:09 PM
Subject: Re: [oslc-core] Motivation and proposal for oslc:archive property
Sent by: <oslc-core@lists.oasis-open.org>
Would it also make sense to add some guidance for service providers on whether to exclude / include archived" resources in search, query and other services? I would guess that majority of scenarios would expect that the "archived" resources are automatically excluded from certain services - e.g. Delegated UI for selection.
Sincerely,
___________________________________________________________________________
Samit Mehta
IBM Rational Software
From: Steve K Speicher/Raleigh/IBM@IBMUS
To: "OASIS OSLC Core TC Discussion List" <oslc-core@lists.oasis-open.org>
Date: 10/01/2014 08:01 AM
Subject: [oslc-core] Motivation and proposal for oslc:archive property
Sent by: <oslc-core@lists.oasis-open.org>
Motivation:
In typical lifecycle management tools, resources are rarely deleted. They instead are marked with such a state as not longer being "active" or "available", some refer to this state as being "archived". By having a uniform way to express whether a resource is in this state or not, allows for a consistent way to build queries and solutions that federate information from various tools.
Proposal:
The term for being archived would be
http://open-services.net/ns/core#archived
and it would take a boolean value. If this property is absent then the resource is not archived.
This has a semantically different meaning than existing oslc:hidden [1], which indicates a hint as to whether the resource or property should be included in a UI. oslc:archived would be used to express the state of a resource, an application may or may not decide to hide these in the UI.
Timeframe:
I suggest this be included in Core 3 common vocabulary.
[1]: http://open-services.net/bin/view/Main/OSLCCoreSpecAppendixA#oslc_ResourceShape_Resource
Thanks,
Steve Speicher
IBM Rational Software
OSLC - Lifecycle integration inspired by the web -> http://open-services.net
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]