[oslc-core] [Oslc-pm] Review of PerfMon spec
John Arwe
johnarwe at us.ibm.com
Tue Jan 8 11:13:07 EST 2013
> 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-core_open-services.net/attachments/20130108/3a393523/attachment.html>
More information about the Oslc-Core
mailing list