[Oslc-pm] Review of PerfMon spec

[John Arwe]

> 5. This spec depends on other specifications that have not finalized
> (ESM and Recon). Either coordinate the finalization with or after 
> the dependent specs, or remove the dependency on these specs. 
> 
> Do you consider vocabulary re-use a dependency? Or is there some 
> other reason you considered the pm spec to have a dependency?
> 
> [jc: yes, if the vocabulary is referenced and required for the use 
> and understanding of the specification.  the concern is that before 
> the dependency is finalized it might change, and thus affect the 
> specification after it is finalized.]
> 

This one I was not specifically asked about, but I'm going to weigh in 
anyhow.  I think this is an issue Core is ultimately going to need to take 
up even if this review was not formally "from" Core, given how far from my 
thinking the comments sound like they are.  Re-using "what is" is hardly 
something the WG did lightly, and I certainly thought I thought it 
through.


Reconciliation/CRTV:   Having just searched [1] again, I find exactly one 
use of Reconciliation (namespaces section when crtv is "defined", as the 
text of a hyperlink), and many of crtv vocabulary terms; all of the latter 
either in the descriptions of predicates whose type is Resource + 
Reference and made exemplary explicitly using the Core-approved 
boilerplate text, or in the "Resource Properties" intro paragraph where 
they are similarly qualified).  As long as the re-use is all exemplary, as 
I think it is here, I disagree that it is required for the use or 
understanding of the spec.  I think it is incrementally *easier* to 
understand by using those examples, sure.  If Core were to ultimately 
determine that this dependency is unacceptable (would gate Perf Mon's 
finalization) in the absence of a finalized Reconciliation spec, then I 
suspect the PerfMon WG would (path of least resistance) move that content 
into a non-normative companion document.  I don't see how that helps 
readers or adopters, but it seems like that would remove the dependency. I 
think Core as a whole needs to clarify its thinking on this, both in terms 
of what it ultimately wants and the policies in place to produce that 
outcome, and get on the record so the Perf Mon WG has more time to 
incorporate Core's thinking into its documents.  FWIW, I expect the same 
pattern in other ISM domains in the future ... there is nothing 'special' 
about PerfMon in this regard.


EMS: Here I think there is a requirement from PerfMon on EMS, so the 
discussion becomes one of what needs to be true in order for Perf Mon's 
re-use to be "safe".  If we accept the current state in OSLC of vocabulary 
documents defining classes, properties (predicates), resources (terms that 
are neither classes nor properties - Perf Mon has 0 of these, in case it 
turns out to matter), and the prose semantics of each, and the domain 
specifications defining a profiled use of those entities (effectively a 
resource definition table == a resource shape), then in theory what we 
need is some guarantee that the (subset of the ) vocabulary PerfMon 
depends upon will not change.  The shape could be defined in either spec 
(or both) without hurting any implementations, I assert.  If the EMS 
working group agreed to hold the re-used vocabulary constant, would it 
satisfy the dependency in your minds?  If not, what additional would be 
needed and why?   Perf Mon believed/s that their ability to re-use 
EMS:Measure without changes was a feature (good thing), not a defect.

There is precedent in Core for modifying a domain vocabulary without 
re-opening the associated finalized domain specification, so I don't think 
we can say that a vocabulary's "status" is identical to the spec's.  Nor 
do I think we can say that the WG owning the vocabulary must have a 
finalized domain spec dependent on every vocabulary entity (same precedent 
case) in order to be "safe" for re-use.

The simple "path of least resistance" approach, for a working group whose 
members do not want to delay their finalization indefinitely (until the 
other WG resumes active development, etc.), would be to copy everything 
into a namespace they control (here: copy EMS:Measure and the 4ish 
properties PerfMon needs into the PM namespace), thus removing the 
dependency and (as a consequence) establishing a "measurement island" in 
PM purely because of the vagaries of the schedules of those involved -- 
there is a large set of EMS-draft vocabulary that Perf Mon has no stated 
intent to re-use in any way, so this really is an island getting created. 
The onus would then by on the other WG (EMS) to re-use PM (or justify why 
NOT to re-use work that started out, by definition, to be exactly what EMS 
needed) in EMS's domain spec when it resumes.  If that is the effect Core 
wants, the right policies and incentives are in place.  It seems to me a 
perverse result, and one that *could* be solved without creating this 
effect via the agreement above.  It is up to Core to enable it however. 

Since several of us are on Core ;-) and there is a meeting next week, 
perhaps we can get this on the agenda.


[1] 
http://open-services.net/wiki/performance-monitoring/OSLC-Performance-Monitoring-Specification-Version-2.0/

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/20130108/3a393523/attachment-0003.html>