[oslc-cm] [Oslc-Automation] Some comments on Actions spec (most from CM perspective)
John Arwe
johnarwe at us.ibm.com
Thu Jan 30 13:40:55 EST 2014
I like fewer terms (one desired state)... the resource shape (aka resource
definition table text) is where the "is likely to be an X" should live.
That's domain-specific, so it does not pollute the vocabulary term's
definition.
Domain CM reusing a Domain!=CM term might cause some "ick, it's a
cross-domain dependency" knee-jerk reactions, but if we're comfortable
re-using DC then Automation is no different in principle, i.e. while we
might hate cross-domain SPEC dependencies, we should be completely
comfortable with cross-domain VOCABULARY re-use.
I tend to split the difference on the descriptions; I've seen in many
contexts that when we try to be completely generic, the result is
incomprehensible to anyone not in That Meeting(s), so I add an a specific
concrete example (clearly marked as such) alongside it. I.e.
<oslc_auto:desiredState >
a rdfs:Property ;
rdfs:comment "The intended (domain- or provider-dependant) value of a
resource's (domain-dependant) 'state' property after some (future, present
or past) process, transition or change. It is expected that this will be
a resource reference to a definition of a valid state on the service
provider. For example, in the OSLC Automation domain this is used to
indicate the desired state of the Automation Request based on values
defined in the OSLC Automation specification and, optionally, by the
service provider." ;
rdfs:seeAlso oslc:StateTransitionAction ;
.
Best Regards, John
Voice US 845-435-9470 BluePages
Tivoli OSLC Lead - Show me the Scenario
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-cm_open-services.net/attachments/20140130/e6b4175a/attachment-0003.html>
More information about the Oslc-Cm
mailing list