> 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
