[Oslc-Automation] Oslc-Automation Digest, Vol 39, Issue 3
Tim Friessinger
TFRIESS at de.ibm.com
Thu May 15 09:20:17 EDT 2014
Hello,
further comments/ answers:
MP>[Sub-domains: "Depending on the sub-domain, an OSLC client can expect
predefined values for the following attributes". Without defining any
specific
sub-domains, I'm not sure this communicates much information. Do you mean
"Sub-domains may specify what sub-set of these predicates they use"? Or
maybe "Sub-domains may specify which values they support for each of these
properties"?]
TGF> My intention here was to express, that the Avail Spec doesn't
specifies predefined values for the listed attributes (like
oslc_avail:rtoTarget, oslc_avail:xyzState, oslc_avail:SAL...), because the
range of possible values can be different from implementation to
implementation. So it's not really useful to specify possible values at
this point.
But: If someone specifies a sub-domain for Availability, e.g. better
represent its own availability product (like Jürgen & I with System
Automation for z/OS), he is free to specify predefined values for these
attributes in his sub-domain. For example SA z/OS's resources have a
compound state with a clearly specified range of values. Of course our
Service Provider implementation will use exactly the same range for
oscl_avail:compoundState. If we choose to specify an SA z/OS sub-domain, we
would specify this range than there.
So I think I want to go with "Sub-domains may specify which values they
support for each of these
properties".
MP>[Delegated UIs: I'd suggest "SHOULD" for AR, AG, RG and RM selection
dialogs, as I
expect UI-based clients will really want to use these. Creation dialogs
might not be appropriate for all providers, so MAY seems appropriate for
them.]
TGF> Ok, I had in mind that the Auto Spec uses "MAY" for selection as well,
but I was wrong here. I already have played around with UI Delegations in
our prototype and it works quite well,
but we have decided not to provide them in our first real implementation of
the SA z/OS Service Provider. So that might be the other reason why I've
chosen "MAY"...but after all we still have no conflict when it is changed
to "SHOULD".
MP>[Predefined properties: These are individuals (values), not
properties.The sub-headings are
ok, as they are the properties that the values are for, but the to-level
"Predefined properties" heading seems wrong to me.]
TGF> You mean that this are technically "predefined values for (some)
properties"? And the term "predefined properties" could be misunderstood in
a way like "here are some more properties,
that we forgot to define for the several resources"?
MP>[PreDef props, compountState: Does "warning" mean "currentState does not
match
desiredState, but may do at some time in the [near] future" and "problem"
mean "they do not match, and the attempt to move to the desired state
failed and cannot be [automatically] retried"?]
TGF> When I wrote this, I somehow had log messages in my mind where
"WARNING" messages normally tell you about an event that happened, but from
what you can recover, while a PROBLEM or ERROR message normally is
something really critical. The more I think about it, the more I like your
first thought with only a "yes/match" and "no/no-match" as predefined
values. An implementation always can add additional values if necessary.
And I see some problems if we start to describe in great detail what the
difference between "warning" and "problem" is. I think this is something
that everybody sees in a different way and we have the risk that someone
who implements Availability doesn't agree with our definition. So better
keep it simple.
MP>[Service Level Properties: Are these properties or values? If values
how do these relate to the predicates of the same name?]
TGF> I forgot to add a "TO DO" mark here. If think the only property of
this list where predefined values make sense is the oscl_avail:AEC; simply
because the AEC (availability environment classification) specifies several
levels of availability, and we can use these levels as predefined values.
For example I have no idea what values we could predefine for SLA. In my
mind the SLA-property could be more like a reference to a document, holding
a real SLA contract.
MP>[If there is only ever one master, would it be better
for this to be a property on the redundancy Group pointing to the master?]
TGF> I've thought about this as well, but decided to use the more general
"redundancyRole"-property for this. Master and slave as predefined values
are maybe a not complete list; I'm still
thinking about good naming for other values. I think there are a lot of
real-world scenarios out there, that are highly available but don't use the
master-slave concept. Think of a workload-balancer which balances HTTP
requests to several webserver instances. All the webservers are equal,
there's no master service.
MP>[Availability Component = Availablility Resource? Or = {AR, AG, RG,
RM}?]
TGF>Good finding, in an initial draft I used Availability Component as name
instead of Availability Resource. Must have forgotten to replace that one.
MP>[You don't have any text about achieving any of those scenarios. In
particular, about how the client can change the condition of an availablity
resource. We don't need to explain how to achieve the scenarios - that can
be left for the scenario pages - but I don't think there's enough in the
spec for a reader to do it themselves...../link to AutomationPlans via the
dcterms:contributor link. ]
TGF> How mandatory are scenarios for a spec? I'm asking because I'm not
really sure if I'd like to really enforce the dcterms:contributor-link of
the AR to be a reference to an AutoPlan.
The easiest way to change an AR (or its AC) would be to make a direct
UPDATE to the AR/ AC itself, like setting the oslc_avail:desiredState from
"Offline" to "Online".
>From a System Automation for z/OS point of view, you shouldn't manually do
that. You tell SA z/OS to do this for you (including maybe a bunch of
additional tasks, that are necessary for this goal, like starting
pre-requisite systems as well etc.)
That's why for an SA z/OS Service Provider the concept of Automation Plans,
that change the state of one or more AR, matches pretty will. Other
implementers of Avail may see this different and want to update AR/ACs
directly without a detour via an Automation Plan.
That's by the way the reason why I mentioned foaf:Person as possible
reference for the dcterms:contributor-link. In case a Service Provider
allows direct manipulation of an AR's state by a user, the user that did
this chance could be tracked by the dcterms:contributor property.
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:
pic20996.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
oslc-automation-r
equest at open-servi
ces.net To
Sent by: oslc-automation at open-services.net
"Oslc-Automation" cc
<oslc-automation-
bounces at open-serv Subject
ices.net> Oslc-Automation Digest, Vol 39,
Issue 3
08.05.2014 15:42
Please respond to
oslc-automation at o
pen-services.net
Send Oslc-Automation mailing list submissions to
oslc-automation at open-services.net
To subscribe or unsubscribe via the World Wide Web, visit
http://open-services.net/mailman/listinfo/oslc-automation_open-services.net
or, via email, send a message with subject or body 'help' to
oslc-automation-request at open-services.net
You can reach the person managing the list at
oslc-automation-owner at open-services.net
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Oslc-Automation digest..."
Today's Topics:
1. This week's meeting - agenda (Martin P Pain)
2. Availability Spec review - my feedback (Martin P Pain)
----------------------------------------------------------------------
Message: 1
Date: Thu, 8 May 2014 14:00:33 +0100
From: Martin P Pain <martinpain at uk.ibm.com>
To: oslc-automation at open-services.net
Subject: [Oslc-Automation] This week's meeting - agenda
Message-ID:
<OF5DD93DAA.E2DD12F4-ON80257CD2.0047479D-80257CD2.00477ACD at uk.ibm.com>
Content-Type: text/plain; charset="us-ascii"
Aside from the usual, the agenda for today's meeting is:
1. Update on review of Automation 2.1 and Actions. (OASIS Core TC have
assigned people to review them, but it'll be at least a few more weeks I
expect).
2. Review of Availablity specification.
I've got some comments (in progress) that I will be sending out to the
mailing list, rather than discussing on the call. If anyone else has
feedback to give on the call, then we can do so, otherwise it will be a
very short call, mainly reminding people to have a look at the spec.
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
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/20140508/67aba39f/attachment-0001.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/20140508/67aba39f/attachment-0002.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/20140508/67aba39f/attachment-0003.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/20140508/67aba39f/attachment-0001.gif
>
------------------------------
Message: 2
Date: Thu, 8 May 2014 14:41:40 +0100
From: Martin P Pain <martinpain at uk.ibm.com>
To: oslc-automation at open-services.net, Juergen Holtz
<HOLTZ at de.ibm.com>, Tim Friessinger
<TFRIESS at de.ibm.com>
Subject: [Oslc-Automation] Availability Spec review - my feedback
Message-ID:
<OF0FE71A1B.C5D778CF-ON80257CD2.0031074B-80257CD2.004B3EAA at uk.ibm.com>
Content-Type: text/plain; charset="us-ascii"
Here is my feedback on the original OSLC Availablility draft spec pdf (
http://open-services.net/wiki/automation/Availability-Specification/)
Key to my feedback notations:
* - A minor point, indicated by a leading hyphen/minus sign. (In grey in
the original HTML email)
* . A medium-level point, indicated by a leading period/dot.
* + An important point, indicated by a leading plus sign.
* . "In quotes, -deleted- words are in red strikethrough with a hyphen
either side , _inserted_ words are in green underline, with an underscore
either side (in the original HTML email - which I believe you can find in
a link in the archives)."
Here is my feedback. I suggest discussing this via e-mail, as getting as
many point as possible sorted via e-mail should be more efficient than on
the call. Anything contentious or that requires in-depth discussion can be
discussed at the meeting next week. There are lots here, including many
minor ones. Hopefully they're useful. Feel free to question anything
(anyone). There are a couple of questions aimed at John Arwe for
clarification - these are makred with "John" in bold.
Editorial comments:
* - The wiki page doesn't need to be "workgroup only".
Introduction:
* - Would this be better to extend Automation, to make best re-use of
Automation's plans?
* - To be able to describe a system that is (highly) available
Terminology:
* - "Availability condition" - to me, "condition" suggests "requirement"
(e.g. boolean expression, if-statement). However, on Googling it, the
sense of "state, situation" does come out as the primary definition, so I
won't make a fuss. "State"/"Status" would also have its problems (sense of
state-machine versus wider condition). I've just mentioned it to make sure
you've thought about the possible ambiguity when looking at the term
"availability condition" when not next to its definition as it is in this
section.
* - "Recommended as a specialization of an Availability Group." (also for
"...of an Availability Resource")
Compliance:
* . Footnote 4: "3Support for all HTTP methods for all -automation-
_availability_ resources is not required "
Namespaces:
* - I expect John would suggest "oslc-availability" for the standard
prefix, but oslc_avail is more consistent with Automation 2. I don't mind
either way.
* . I would suggest something longer in the namespace URI though, perhaps:
http://open-services.net/ns/availability# I know other specs used very
short forms, but that caused problems with "Configuration management"
versus "change management", and I believe the more recent convention is to
use a longer string in the URI. Consistency here isn't important, as the
URI is repeated less than the prefix.
Availability definitions:
* - "It is recommended that any additional properties exist in their own
unique namespace and not use the namespaces defined in this specification.
" - I expect this was copied from Automation, but this could be a stronger
requirement. It would be bad practice to define properties in the
namespaces defined in this specification without the agreement of the
working group or technical committee responsible for maintaining the
namespace. (A few paragraphs down we make it a SHOULD - I guess that's the
same as "recommended" in prose).
* + The arrow and name of the relationship between Group and Availability
Resource (AR) appear to disagree with each other. Either the group is
pointing to a resource as a "member", or the resource should be pointing
to the group(s) it is a "memberOf". In the resource tables it suggests
that the link is pointing from the AR to the Group.
* . When I first looked at this diagram I wasn't convinced about
Availability Condition (AC) being a separate resource. Having read later
it looks like there can be multiple ACs for an AR, each as a snapshot at a
given timestamp (dcterms:created). Is that the intention? If not, what was
the reasoning behind them being different resources?
* . I'm not sure dcterms:contributor is the best relation to use for the
link to resources that the AR is affected by. dcterms deifne its raneg as
Agent, which is "A resource that acts or has the power to act. ". Is it
your intention to link to resources that can act on on the AR? As opposed
to ones that the AR acts on? (Or can affect the AR's state not by acting
on it, but merely by changing its own state). The definition in the
resource table further down suggests the usage is correct - the target of
the link is actively acting on the AR. This isn't clear in the diagram
whether the contributor is affecting the AR actively, or merely its state
is reflected in the AR.
Resource: AR
* - dcterms:description "Descriptive text (reference: Dublin Core) about
_the_ resource"
* + Availability-specific properties: Please create a vocab document (or a
wiki page to use as a draft) to define each of these terms outside the
conext of these particular resource tables. This helps create vocabularies
with more value and reusability, and also helps discover any ways in which
the terms can be improved even inside the scope of the resource tables.
* + oslc_avail:actualCondition: You have read-only set to true. I expect
this is consistent with some other specs, but it's worth considering that
in some scenarios (although admittedly not within our defined scope) might
have the resources stored in a separate repository from the actor who
determines their contents. In that case, they need to be updatable.
John: What does "read-only" technically mean here? The most important
question here for this version is: would changing the read-only flag for a
property in a subsequent version cause any problems? And is a provider
non-compliant if they allow it to be written? If not, I'm happy to leave
it, as it can always be changed if anyone raises a scenario for those
cases.
* + oslc_avail:memberOf. Is there a particular reason why the link is
pointing in this direction, and not from the group to the members? It
would seem to me that you might more often want to find all members for a
group (part of the scenario "Obtain redundancy information for workloads"
- even if you do have to start at an AR). If we require looking up of
reverse links, we ought to specify exactly how this is expected to be
achieved. I know it's possible with query capabilities, but we ought to
clearly spell out how, to make implementors lives easier. (Whichever
direction the link goes in we might have to do reverse link lookups, but
if the link pointed in the other direction it would only have to be one,
rather than all but one of the group's members. But then again you have to
do the lookup to find out if it's in a group. Perhaps that was your
reasoning, if so you've probably got the link in the correct direction.)
* + oslc_avail:memberOf: Say in the description "It is expect 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".
Resource: AC
* + compoundState. Mention and link to the predefined values in the
description. Can providers provide their own values? If they can, there
may be a better alternative: The Change Management specs found that for
their states it was useful to add in "state predicates" [1]. These are
single-value properties that indicate some semantics of the resource's
current state.e .g. oslc_cm:closed=[true|false] [2]. So in this case we
could define this as oslc_avail:consistentState=[true|false]. If it is
true, you can read either and get the actual state knowing it is also the
desired state. If it's false you can read whichever one you need knowing
that actual & desired are not consistent. (Is this explicitly mentioned in
a scenario? Whenever someone asks about the reasoning behind something, as
I'm doing here, it would be useful to add a note to any applicable
scenario(s)' wiki pages about that reasoning and how it supports that
scenario. [Although I admit I haven't done this in my work on the Actions
spec.]) See comment below in "Predefined properties" section about
warning/problem distinction. (If we still want that distinction, but also
wanted to use state predicates, we could have a second one for the
"problem" state... maybe).
* + desiredState & currentState. Mention and link to the predefined values
in the description. Say whether provider-specific values are allowed.
* - If provider-specific state values are allowed (which might be a good
idea to support extensibility) then we might want to consider state
predicates for online, offline, stopping and starting. On the one hand
this isn't required by the existing scenarios, but on the other hand it
provides most flexibility going forwards.
* + mttf & mttr: What type of resource? Options probably include: using an
integer, not resource, and specifying units in spec. Or using (hopefully
re-using) some existing time-period resource that can specify its own
units.
Resource: Availability Group
* + dcterms:created -remove "The point in time this condition has
occurred."
* + dcterms:modified: Do we want to make it explicit that new members
added to the group update this? (As they don't add any new triples to this
group resource, so it may not by default.) What about changes to resources
- I guess they don't update this timestamp - do we want to make that
explicit?
* + AEC: Does the HRG AEC have an RDF vocab/representation? If so, can we
link to it? If not, how is this represented?
* . currentlyActive: This predicate name doesn't indicate "count". I'd
prefer something like "currentlyActiveCount" or "numberActive" or (to find
a verb form) "hasActiveMembers" (note the trailing "s" - if it were
linking to a currently active member, it would not have an "s", so this
"S" could [very] subtly suggest that it is a count. But I don't like this
one much, due to that being very subtle.)
* + John: Can range be used like this?
* + SLA: Mention and link to the predefined values in the description. Say
whether provider-specific values are allowed.
Resource: Redundancy Group
* + Should this be an rdfs:subClassOf Availability Group. i.e. why is it
"often" an AG, not always? (Admittedly, I think we can always add
subClassOf in future, but removing it would be harder).
* . "maxActiveTarget", "minActiveTarget". Who is this a target for? Is
this what the provider is trying to achieve, or could this be instructions
to a consumer to start/stop members to meet this target? Could it be
either, or do we want to specify one?
* . "redundancyCapability: Description: Starting with "Information
about..." makes it sound, to me, like it's going to be a resource. Perhaps
"An indication of level of redundancy provided by this group." might be
more fitting for an integer value.
* + synchronizationType: Mention and link to the predefined values in the
description. Say whether provider-specific values are allowed.
Resource: Redundancy Member
* + Again, same question about subClassOf.
* + redundancyRole: Mention and link to the predefined values in the
description. Say whether provider-specific values are allowed.
Sub-domains:
* + No subdomains are explicitly defined.
* + If we only want vendor-specific sub-domains, should we specify an
rdf:Class to use as the rdf:type value of the resource at the target of
the sub-domains identifier URI, so generic consumers can identify which
URIs identify Availability sub-domains? (i.e. This would be used in the
vocab documents that define those sub-domain URIs).
* + In the example, a value is used for "System Automation for z/OS"
sub-domain. (1) This value isn't defined in this spec (at least not that
I've seen so far) so shouldn't use this spec's namespace. An example.com
namespace would be appropriate for an example value. (2) If we want to use
this value in IBM implementations (I presume we do) then it's still in the
wrong namespace. It's a vendor-specific term, so I'd suggest it would be
better in an ibm.com or jazz.net namespace (the latter is Rational-owned,
but has an existing process for publishing public RDF vocab documents, so
might be the path of least resistance). As far as the WG should be
concerned: it's a vendor-specific term, discuss it inside the vendor.
(Well, that's my opinion). We can always provide a list of links to known
vendor-specific terms in an informative section of the spec.
* + "Depending on the sub-domain, an OSLC client can expect predefined
values for the following attributes". Without defining any specific
sub-domains, I'm not sure this communicates much information. Do you mean
"Sub-domains may specify what sub-set of these predicates they use"? Or
maybe "Sub-domains may specify which values they support for each of these
properties"?
Creation Factories/Query Capabilities:
* - "at least one Creation Factor_y_-ies- entry" (perhaps use the
qualified name for the type or predicate)
* - "at least one Query Capabilit_y_-ies- entry" (ditto)
* + "SHOULD support the oslc.properties syntax " SHOULD should be bold.
Delegated UIs:
* + RedundancyMember is missing from table
* . I'd suggest "SHOULD" for AR, AG, RG and RM selection dialogs, as I
expect UI-based clients will really want to use these. Creation dialogs
might not be appropriate for all providers, so MAY seems appropriate for
them.
Predefined properties:
* + These are individuals (values), not properties.The sub-headings are
ok, as they are the properties that the values are for, but the to-level
"Predefined properties" heading seems wrong to me.
* + I know Automation uses a lower-case initial letter for its states, but
I believe the current convention for these sorts of URIs ("individuals")
is to use an initial capital. e.g.
http://open-services.net/ns/availability#Offline.
* . These URIs will point to resources defined in the Availability vocab
document. Should they have a particular rdf:Class for their rdf:type
property, to identify what they are values of/for?
* . Some of these values might be appropriate for contribution to the
Common IT Resource Vocabulary:
http://open-services.net/wiki/reconciliation/Common-IT-Resource-Type-Vocabulary-Version-2.0/
(On the other hand, as all of the properties and values in this spec
relate to resources, and specifically to their availability, perhaps we
should keep them in a separate Availability namespace, but have that
linked from the Common IT Resource Vocabulary, sort of as a
sub-vocabulary.)
* . compountState: Does "warning" mean "currentState does not match
desiredState, but may do at some time in the [near] future" and "problem"
mean "they do not match, and the attempt to move to the desired state
failed and cannot be [automatically] retried"? The description for
"problem" suggests that, but what warning says - "the availablity resource
is still usable" - seems to me to be orthogonal to whether or not it meets
its desired state. It's usable if the currentState is "online", and not
usable if it's any other state, right? I'd suggest letting compoundState
just say whether or not the currentState matches the desiredState
(yes/ok/match, or no/doesn't match. possibly with a "may match soon"/"in
progress" option), and currentState say whether or not the resource is
usable or not. Perhaps this was your intention, in which case I think the
"warning" value needs a better description- and perhaps renaming to
"InProgress" or "Changing".
* . Service Level Properties: Are these properties or values? If values
how do these relate to the predicates of the same name?
* . redundancyRole: If there is only ever one master, would it be better
for this to be a property on the redundancy Group pointing to the master?
HTTP method support:
* + Availability Component = Availablility Resource? Or = {AR, AG, RG,
RM}?
[1]
http://open-services.net/bin/view/Main/CmSpecificationV2?sortcol=table;up=#State_Predicates
[2] Approx 2 pages down from:
http://open-services.net/bin/view/Main/CmSpecificationV2?sortcol=table;up=#Resource_ChangeRequest
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
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/20140508/65a23cb7/attachment.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/20140508/65a23cb7/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/20140508/65a23cb7/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/20140508/65a23cb7/attachment.gif
>
------------------------------
Subject: Digest Footer
_______________________________________________
Oslc-Automation mailing list
Oslc-Automation at open-services.net
http://open-services.net/mailman/listinfo/oslc-automation_open-services.net
------------------------------
End of Oslc-Automation Digest, Vol 39, Issue 3
**********************************************
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pic20996.gif
Type: image/gif
Size: 1851 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20140515/7731f07b/attachment.gif>
More information about the Oslc-Automation
mailing list