[Oslc-Automation] Availability spec: "At least one binding" text (was: First draft Availability Vocabulary/ public holiday in Germany)
Martin P Pain
martinpain at uk.ibm.com
Wed Jul 16 12:19:39 EDT 2014
As the definition of oslc:action in that "Common property" section is the
main definition of the use of that property, My point of view is that we
inherit the same semantics. In other words, we could equally say in the
Availability spec "when is ia an oslc:Action, it will have..." as a
ConditionAction has a binding because it is an Action (and is
currently-available).
So perhaps we could leave that sentence out of the Availability spec...
but then again that would be assuming people are familiar with the Actions
spec, which is not a safe assumption. Or we could say "when it is an
oslc:Action (such as an oslc-availability:ConditionAction), it will have
at least one binding since it is currently available". I think this would
capture more of the reason why it will have a binding, but has the
downside of adding more text.
Martin Pain
Software Developer - Green Hat
Rational Test Virtualization Server, Rational Test Control Panel
OASIS Open Services for Lifecycle Collaboration - Automation technical
committee chair
E-mail: martinpain at uk.ibm.com
Find me on: and within IBM on:
IBM United Kingdom Limited
Registered in England and Wales with number 741598
Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU
From: Tim Friessinger <TFRIESS at de.ibm.com>
To: Martin P Pain/UK/IBM at IBMGB,
Date: 16/07/2014 16:32
Subject: Re: [Oslc-Automation] First draft Availability Vocabulary/
public holiday in Germany
Hi Martin,
I'm working through your comments to my last availability draft right now
and you asked if I've copied the sentence "when it is an
oslc-availability:ConditionAction , it will have at least one binding
since
it is currently available" somewhere.
And yes, I've copied it from this source:
http://open-services.net/wiki/core/Exposing-arbitrary-actions-on-RDF-resources/
See section"Common Property: oslc:action".
Mit freundlichen Grüßen / Kind regards
Tim Friessinger
System Automation for z/OS Development
IBM Software Group, Tivoli
IBM Lab Boeblingen, Germany
Phone: 49-7031-16-2535 IBM Deutschland
(Embedded
image moved
to file:
pic13467.gif)
E-Mail: tfriess at de.ibm.com Schoenaicher Str. 220
71032 Boeblingen
Germany
IBM Deutschland
Research &
Development
GmbH /
Vorsitzende des
Aufsichtsrats:
Martina Koederitz
Geschäftsführung:
Dirk Wittkopp
Sitz der
Gesellschaft:
Böblingen /
Registergericht:
Amtsgericht
Stuttgart, HRB
243294
Martin P Pain
<martinpain at uk.ib
m.com> To
Tim Friessinger/Germany/IBM at IBMDE
07.07.2014 14:08 cc
oslc-automation at open-services.net,
"Oslc-Automation"
<oslc-automation-bounces at open-servi
ces.net>
Subject
Re: [Oslc-Automation] First draft
Availability Vocabulary/ public
holiday in Germany
1. AvailabilityResource
a) The title of the properties table is "AvailabilityComponent Properties"
when it should be "AvailabilityResource Properties"
b) oslc:action - The description is good on the whole, but this sentence
sounds wrong: "when it is an oslc-availability:ConditionAction , it will
have at least one binding since it is currently available." It should
always have at least one binding, as it is linked to using the
action:actino predicate, which asserts that it is "currently available"
which requires at least one binding. If you copied this from somewhere,
I'd
be interested to know where to see if the source has the same problem.
(Also is ConditionAction the old name for ChangeConditionAction?)
c) dcterms:identifier. exactly-one? Does this really need to be required?
Again, I presume this is just copied from somewhere. It adds a burden
(though a small one) on to providers that I'm not convinced is needed.
d) dcterms:modified - "An modification to an Availability Resource's
AvailabilityCondition (oslc_asset:state) is not a resource modification,
and therefore is not reflected by an update of this property." I'd make 2
changes: "An modification to an Availability Resource's
AvailabilityCondition (linked via oslc_asset:state) is not a resource
modification to this resource, and therefore is not reflected by an update
of this property."
e) dcterms:title "If unique, it can be used to identify different
automation resources." -> "If unique, it can be used to identify different
availability resources" (Although I'm not sure that sentence gives much
value. I expect it's an encouragement to service providers to try to form
unique names for the benefit of human users.)
f) oslc-availability:rto - Link for "ems:Measure" links to "foaf:Person".
Also, I can't fine anything in EMS that defines lengths of times. The
drafts suggest that they intended to, but I can't find anything concrete.
If we need to include it, the "best thing" (given unlimited time) moght be
to move something from EMS to a stable form, but (1) we're limited in
time,
and (2) I'm not convinced we need RTO for the stated scenarios, so I
suggest we drop this property. (We could add a non-normative setence or
note somewhere says what implementors should do if they want a Recovery
Time Objective property. At very least they could use Delegated UI
Resource
Previews and include it in the HTML there, so at least it's available to
human users, even if not available programatically.)
2. AvailabilityCondition
a) I can't remember what we said abotu compoundState, currentState and
desiredState, but it looks like it hasn't been applied. (I think we had
agreed (or somewhat agreed) on having a boolean property for
"matchesDesiredState" or "desiredStateMismatch" or something like that,
rather than an open-ended "compoundState" property).
At this point I'm remembering that I think you said that you only
introduced the Actions things. (Although I think I found some new points
that I didn't include last time.) So I'll skip forwards to find anything
else about Actions.
3) "OSLC Actions and Availability"
a) Earlier in the spec we referred to
"oslc-availability:ChangeConditionAction", here we say
"oslc-availability:ConditionAction" - are these supposed to be the same? I
don't mind which one we pick.
b) "Profiles". Be clear what you mean by "profile". IS this section
referring to profiles already defined in the Actions spec ("OSLC Actions
Specification Profiles", link to
http://open-services.net/wiki/core/Actions-2.0/#Specification-profiles),
or
are these new concepts being defined in this spec, "OSLC Availability
Specification Profiles"? The descriptiono f the profiles looks like the
foremr, but the first paragraph under "Profiles" could clarify this.
c) HTTP request profile/pattern - The link in this section is actually to
an "Interaction Pattern", not to a "Actions Specification profile". The
link to the profile is here:
http://open-services.net/wiki/core/Actions-2.0/#profile_POST_resource_shape
. (The difference is this: the Spec Profiles say which Interaction
Patterns
the providers MUST provide bindings for. Then interoperability is based on
which profiles a client & server are compliant with, so we have a finer
granularity of compliance than just a "yes" or "No" at the whole-spec
level.)
d) At first read, I like the way we require Actions Spec Profiles based on
the synchronous capabilities of the provider. However, when thinking about
this from a client's point of view, clients then need to implement both
profiles in order to be interoperable with all "OSLC
Availability-compliant" servers. Perhaps we should make The AutoRequest
Actions Spec Profile a MUST for all providers? (There's nothing to stop
them just using the HTTP one if they really want to, but then if they
claim
that they are compliant with OSLC Availability then they are wrong - it's
just they'd be re-using a subset of this spec.)
e) Dialog profile: This isn't actually an Actions Specification Profile,
it is just an Interaction Pattern. If having an Actions Spec Profile for
dialogs would be useful we have two options : (1) Put it in to the Actions
spec. (2) Define it in this specification (probably as a Spec profile of
the Action Spec). #1 sounds better, as it is still in the control of this
WG (although we would have to notify the reviews of the change), and may
well be useful to others.
4) Sub-Domains
a) Do the scenarios cover automated vs manual execution? Perhaps it would
be a small tweak to make one of the existing ones demonstrate the
automated
usage, and another one of the existing ones demonstrate the manual usage.
(But perhaps that would be confusing, as it might reduce clarity as to the
intention of each scenario - but it's kind of what I did with the teardown
scenarios.)
b) Why would a manual sub-domain provider's actions be synchronous?
c) Default sub-domain: I'd suggest including the hash at the end of this
URI, to make it identical to the namespace:
http://open-services.net/ns/availability# (although I think we talked
about
putting these under automation anyway, didn't we?)
Had a quick scan through the rest. The comments about profiles and
sub-domains come up again, but no new comments on the rest of it.
Martin Pain
Software Developer - Green Hat
Rational Test Virtualization Server, Rational Test Control Panel
OASIS Open Services for Lifecycle Collaboration - Automation technical
committee chair
E-mail: martinpain at uk.ibm.com (Embedded
image moved to file:
Find me on: (Embedded image moved to file: pic22385.jpg)LinkedIn:
pic45682.gif)IBM
http://www.linkedin.com/profile/view?id=99869908 and within IBM on:
(Embedded image moved to file:
pic19517.jpg)IBM Connections:
https://w3-connections.ibm.com/profiles/html/profileView.do?userid=12c849c0-ddd5-1030-9b5f-d70a3a891b7f
IBM United Kingdom Limited
Registered in England and Wales with number 741598
Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU
"Oslc-Automation" <oslc-automation-bounces at open-services.net> wrote on
18/06/2014 15:35:09:
> From: Tim Friessinger <TFRIESS at de.ibm.com>
> To: oslc-automation at open-services.net,
> Date: 18/06/2014 15:36
> Subject: [Oslc-Automation] First draft Availability Vocabulary/
> public holiday in Germany
> Sent by: "Oslc-Automation" <oslc-automation-bounces at open-services.net>
>
>
> Hello,
>
> this Thursday we have a public holiday in Germany, so Jürgen and I will
not
> be able to attend the OSLC Automation Meeting.
>
> Nevertheless I've uploaded my first working draft of the Availability
Vocab
> to the wiki:
> http://open-services.net/wiki/automation/OSLC-Availability-Vocabulary/
>
> It reflects some of the updates/ changes I've done to the spec draft
(but
> not all). I think these changes are a good start for a discussion on the
> next Meeting or via mail.
> These are the changes I've made, that are reflected by the vocabulary:
>
> General things:
> ---
> (1) suggested namespace is now "oslc-availability". :)
>
>
>
> AvailabilityResource:
> ---
> (1) Removed dcterms:contributor as link from an AvailabilityResource to
an
> AutomationPlan, will be replaced by oslc:action.
> (2) Removed oslc-availability:actualCondition (reference to
> AvailabilityCondition resource), replaced by oslc_asset:state, because
it
> is basically the same.
> (Quote: Used to indicate the state of the asset based on values
> defined by the service provider. This specification does not define the
> resource for this property, however it should contain a dcterms:title
> property. )
> In the Avail vocab I specify that the range for this property in the
> context of Availability has to be an
> oslc-availability:AvailabilityCondition, which will contain the
> dcterms:title property.
> (3) memberOf: "It is expected that the target of this link will be of
type
> Availability Group (or its sub-type Redundancy Group), but this is not
> necessarily the case." added.
>
>
>
> AvailabilityCondition:
> ---
> (1) Renamed "rtoTarget to rtoRequirement. I think Martin mentioned that
a
> property with name "target" could be misunderstood in a way, that a
> consumer could use this property to achieve a target. I hope
"requirement"
> is more precise.
> (2) {compound, current, desired}State: Added "It is expected that this
will
> be a resource reference to a definition of a valid target type on the
> service provider.".
> (3) mttf, mttr: Suggestion was to be more precise about the type here.
So
> first I thought about making this an Integer and specify, that the
property
> will the mean time to XYZ in milliseconds. But then I discovered the
> ems:Measure.
> So I added "It is likely that the target resource will be an
> ems:Measure, but that is not necessarily the case." to the description
of
> this property. (ems:Measure is part of the OSLC Estimation and
Measurement
> domain).
>
>
>
> AvailabilityGroup:
> ---
> (1) Removed AEC property, since not required for the scenarios.
> (2) Renamed currentlyActive to numberActiveMembers, to more reflect the
> reason for this property.
> (3) SLA: Suggestion was to add "It is expected that this will be a
resource
> reference to a definition of a valid target type on the service
provider."
> to the description, but I think the SLA property should be used as a
> reference to a document containing the service level agreements (or
> containing the SLA itself). So I added this to the properties
description
"
> This can be a String or even a reference to a document, containing the
> Service Level Agreement. How such a SLA is modelled in detail, is not
part
> of this specification.".
>
>
>
> RedundancyGroup:
> ---
> (1) Still not sure if I should use the subClassOf here, pointing to
> AvailabilityGroup. We should discuss this.
> (2) Renamed {max, min}ActiveTarget to {max, min}ActiveMembers. Target
could
> be missunderstood (see above). Maybe {min, max}ActiveMemberRequirement
> would be even more precise, but from a gut feeling this property name
would
> be too long?
> (3) redundancyCapability: Updated properties description to "An
indication
> of level of redundancy provided by this group.
> Calculated by the formula # group members – minActiveMembers – #
> offline/ failed members.".
> (4) synchronizationType: Updated properties description to "Information
> about how this group's members synchronize each other.
> It is expected that this will be a resource reference to a definition of
a
> valid target type on the service provider.".
>
>
>
> RedundancyMember:
> ---
> (1) Still not sure if I should use the subClassOf here, pointing to
> AvailabilitResource. We should discuss this.
> (2) redundancyRole: Updated properties description to "Specifies the
role
> of a resource in the context of Availability in terms of redundancy, for
> example if the resource is a master or a slave component.
> It is expected that this will be a resource reference to a definition of
a
> valid target type on the service provider."
>
>
> Thanks for reading! :)
>
> Mit freundlichen Grüßen / Kind regards
>
> Tim Friessinger
>
> System Automation for z/OS Development
> IBM Software Group, Tivoli
> IBM Lab Boeblingen, Germany
>
>
>
>
>
> Phone: 49-7031-16-2535 IBM Deutschland
(Embedded
>
> image moved
> to
file:
>
> pic56634.gif)
>
> E-Mail: tfriess at de.ibm.com Schoenaicher Str.
> 220
>
> 71032 Boeblingen
>
> Germany
>
>
>
>
>
> IBM Deutschland
> Research &
> Development
> GmbH /
> Vorsitzende des
> Aufsichtsrats:
> Martina Koederitz
> Geschäftsführung:
> Dirk Wittkopp
> Sitz der
> Gesellschaft:
> Böblingen /
> Registergericht:
> Amtsgericht
> Stuttgart, HRB
> 243294
>
> [attachment "pic56634.gif" deleted by Martin P Pain/UK/IBM]
> _______________________________________________
> Oslc-Automation mailing list
> Oslc-Automation at open-services.net
>
http://open-services.net/mailman/listinfo/oslc-automation_open-services.net
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[attachment "pic13467.gif" deleted by Martin P Pain/UK/IBM] [attachment
"pic22385.jpg" deleted by Martin P Pain/UK/IBM] [attachment "pic19517.jpg"
deleted by Martin P Pain/UK/IBM] [attachment "pic45682.gif" deleted by
Martin P Pain/UK/IBM]
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 part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20140716/ad050baf/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 518 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20140716/ad050baf/attachment.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 1208 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20140716/ad050baf/attachment-0001.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 360 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20140716/ad050baf/attachment.gif>
More information about the Oslc-Automation
mailing list