[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