Agenda
- Status of specification review comments
- Do we have a need for an pm:configurationStatus property to handle Enabled/Disabled semantics?
Minutes
- 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?
- Why does spec guidance provide prefix suggestions for other domains? It may be appropriate to suggest a prefix for the perfmon domain, but not others. It is expected define prefixes that are used throughout the rest of the spec, but not so suggest that others use them.
The namespaces section should look more like the other specs and just state: “In addition to the namespace URIs and namespace prefixes defined in the OSLC Core specification, OSLC Performance Monitoring defines the namespace URI of http://open-services.net/ns/perfmon# with a namespace prefix of pm.”
The workgroup thought that the paragraph preceding the table explained why we put the suggested prefixes in the spec and was specific about their usage being optional.
In the samples Turtle is used. Turtle is never even mentioned in the specification. Recommend either include turtle as a MAY representation in the spec, or remove it from the samples.
We will update the “Other” column of the “Service Provider HTTP Method Support” table to say “MAY” in the GET/PUT/POST rows.
-
rdf:type – at least should include perfmon:PerformanceMonitoringRecord, right?
Is there any guidance in the Core Spec on what to put in this property? As I look at different specs (Automation, Change Management) I see different approaches.
Decided we don’t need a configurationStatus property
