History   View   Links to this page 2012 November 28 | 01:17 pm

Absent a formal issue tracking system, this is an attempt to keep things somewhat orderly. Ideally we should list them in priority order, where priority is based on what gates us from moving the spec forward in the process.

Open Issues

Date Opened # within date Summary (1 line) Links to related emails, meetings, etc. Date Closed
2012-10-24 001 Update spec guidelines Linking a Performance Monitoring Record to the Resource it Describes 2012-10-31
2012-10-24 002 Change dcterms:date to one-to-one from zero-to-one 2012-10-31
2012-10-15 001 Define resource shapes or say we have none 2012-10-31
2012-10-15 002 Fill in spec Contributors 2012-10-31
2012-10-15 003 Create Guidance: extending availability status
2012-10-15 004 Create Guidance: extending metric categories
2012-10-15 005 Create Guidance: extending metrics 2012-10-31
2012-10-15 006 Create Guidance: alternatives for linking PMR to “crtv” resource or similar 2012-10-31
2012-10-15 007 Question to WG: Is the previous sentence true??? 2012-10-31
2012-10-15 008 Question to WG: Do we want paragraph copied from Automation on oslc.properties? 2012-10-31
2012-10-15 009 Question to WG: Do we want to be more specific in previous paragraph about which vocabularies to re-use?
2012-10-15 010 Question to WG: Query Capability section inconsistent with earlier statements? 2012-10-31
2012-10-15 011 Question to WG: which is right for Availability Status Property Values? 2012-10-31
2012-10-15 012 ?

Closed Issues

Date Opened # within date Summary (1 line) Links to related emails, meetings, etc. Date Closed

Details

Issue 2012-10-15-001

Spec draft has a placeholder section and link to Resource Shapes page. No page at the other end of that link.

Julie will update to say not having any. Might add later if we automate res def table gen.

Issue 2012-10-15-002

No additional details.

Issue 2012-10-15-003

No additional details.

Issue 2012-10-15-004

No additional details.

Issue 2012-10-15-005

No additional details.

Issue 2012-10-15-006

No additional details.

Issue 2012-10-15-007 {#2012-10-15-007} - Done

The diagram below shows an example of one way that a Performance Monitoring Record resource may relate to the resources it describes. With this option, the monitored resource has a Performance Monitoring record as a class type, allowing clients an easy way to query for resources that also have associated metrics.

Hinges on “what does ‘the resources it describes’ mean?”

Meeting Julie will update diagram, understands question.

Issue 2012-10-15-008 {#2012-10-15-008} - Done

Question to WG: Do we want this next paragraph? Appears it was copied from Automation. we are otherwise silent on oslc.properties.

Consumers of OSLC Performance Monitoring services should note that some resources may have a very large number of related resources, and that some resources may be very large and/or expensive to compute. For this reason, consumers are strongly encouraged to use the oslc.properties parameter to limit the properties returned from a request to the subset required. See Selective Property Values in the OSLC Core Specification.

Meeting Julie: agree conflicts; will remove paragraph. Compliance table has MAY today, perhaps should be a SHOULD; no objections raised.

Issue 2012-10-15-009

The OSLC Estimation and Measurement (EMS) domain defines ems:Measure. This specification re-uses it without modifications, aside from defining additional metric URIs in the Performance Monitoring namespace. Performance Monitoring Record instances will generally re-use units of measure from EMS and other vocabularies.

Question to WG: Do we want to be more specific in previous paragraph about which vocabularies to re-use?

Meeting Julie: suggestions would not hurt, we do re-use QUDT, EMS, DBPedia. Need links to human-readable pages not RDF or RDFS. We have existing sentence about how we re-use EMS, should we say we define sub-classes there? Julie to handle.

Issue 2012-10-15-010 {#2012-10-15-010} - Done

pm:availabilityStatus zero-or-many True Resource Reference n/a An indication of availability. If any value is present, then at least one of them MUST be from the list of URIs defined below. Additional values MAY be present from other namespaces, e.g. to provide more detailed product-specific status. All values present MUST be semantically compatible. Availability Status Property Values

Question to WG: which is right, “reference” (not Either) in the table above, or “inline is valid too” in the paragraph below.

OSLC Performance Monitoring service providers can identify the availabilityStatus using references to property values in the OSLC Performance Monitoring vocabulary or to property values that are not in the Performance Monitoring vocabulary (i.e. in the service provider’s own vocabulary). It is expected that the availabilityStatus values will be URI references to property values, but inline resources defining the availabilityStatus property values are also valid. Performance Monitoring service providers MUST use at least one availabilityStatus (Performance Monitoring Record) defined in the OSLC Performance Monitoring vocabulary in addition to any availabilityStatus values not in the Performance Monitoring vocabulary.

Meeting Julie: Either, will update

  • availabilityStatus - keep as reference
  • disk, process - either

Issue 2012-10-15-011 {#2012-10-15-011} - Done

The Query Capability MUST at least support these parameters:

Question to WG: Inconsistent with earlier statements (MUST support query syntax, compliance table).

Meeting .select and .where are the right two, if we want to require anything. Question is do we want to require anything. Some members feel the minimum is .where. Proposal: .where = MUST, .select = SHOULD.

Issue 2012-10-15-012

No additional details.