[Oslc-pm] Questions on spec draft/vocabulary

[John Arwe]

> One concern I have about the refactoring approach is that the so-
> called "Best Practice" metrics is now going to be whatever a 
> particular provider says they are vs. something that we've asserted.

My reaction is: non sequitir.

Assertion 1: the list of BP metrics is spec content (assertion(s) made 
through the domain spec as a vehicle).  That is true independent of what a 
Web client sees/has to do.  We even can (dare I say should) provide an 
example representation for each the spec does call out as a BP.  That list 
of BPs is independent of the SP.  In reality "that [implication:single] 
list" is probably a set of per-type lists, e.g. "if you are representing a 
VM, here is/are the example/s for doing so; if ... hypervisor, here...; if 
...database, here...", but that's just an optic.

> ... And, clients must always introspect 
> Resource Shapes to know what they're going to get. 

Assertion 2: that is unaffected by the factoring of predicates inside 
observes.  The mechanics are different (you have to AND together a couple 
of predicate URIs) but the set of testable conditions is no smaller.  In 
fact, it's larger (as we discussed) precisely because the combinations are 
bound at run time.

What I mean by that: client code that wants to know what a PM provider 
will return certainly need to introspect the resource shapes (if any) 
exposed by the service provider.  I don't think that shapes are flexible 
enough to communicate "when my PMR describes a CS, my PMR will always 
contain an ems:observes with triples whose predicate/object pairs are Xx, 
Yy, Zz and it may contain Aa, Bb."  Examples might prove me wrong, I admit 
to a constitutional inability to work through >1 level of shape 
indirection in my head.


Or am I misunderstanding your point?

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-pm_open-services.net/attachments/20120927/2356090c/attachment-0003.html>