[Oslc-pm] Review of PerfMon spec
James Conallen
jconallen at us.ibm.com
Wed Jan 2 17:38:21 EST 2013
my 2c,
Thanks,
jim conallen
Rational Design Management (DM) Integration Architect, OSLC AM Lead
jconallen at us.ibm.com
Rational Software, IBM Software Group
From: Julianne Bielski/Raleigh/IBM
To: Steve K Speicher/Raleigh/IBM at IBMUS, James
Conallen/Philadelphia/IBM at IBMUS,
Cc: oslc-pm at open-services.net, "Oslc-Pm"
<oslc-pm-bounces at open-services.net>
Date: 01/02/2013 04:57 PM
Subject: Re: [Oslc-pm] Review of PerfMon spec
Jim, Steve,
We discussed the remaining spec comments on today's OSLC Perf Mon workgroup
call. Below are our responses/questions.
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.]
6. 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.
[jc: I think the main point was, since this is a normative section of the
specification, it should focus on what is required by those implementing
and consuming it. Suggested prefixes, especially for other domains, that
may be in turn used in other places, or combined with this could get a
little confusing.]
8. 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.
24. #Performance_Monitoring_Record
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.
[jc: in general we've used the Change Management specification as the
exemplar for such things, as they tend to lead the other specs.]
-- Regards,
Julianne Bielski, STSM
ITM Core Chief Architect
Tivoli, IBM Software Group
tel: (919) 224-1170 (T/L) 687-1170
e-mail: bielsk at us.ibm.com
"All growth is a leap in the dark, a spontaneous unpremeditated act without
benefit of experience." — Henry Miller
From: Julianne Bielski/Raleigh/IBM
To: Steve K Speicher/Raleigh/IBM at IBMUS
Cc: James Conallen/Philadelphia/IBM at IBMUS,
oslc-pm at open-services.net, "Oslc-Pm"
<oslc-pm-bounces at open-services.net>
Date: 12/10/2012 12:52 PM
Subject: Re: [Oslc-pm] Review of PerfMon spec
Thank you for the great feedback. I've removed from the list below the
comments I have addressed (as of this morning).
A few responses and follow up questions below.
John Arwe, I put your name next to a few I thought you may want to respond
to.
-- Regards,
Julianne Bielski, STSM
ITM Core Chief Architect
Tivoli, IBM Software Group
tel: (919) 224-1170 (T/L) 687-1170
e-mail: bielsk at us.ibm.com
"All growth is a leap in the dark, a spontaneous unpremeditated act without
benefit of experience." — Henry Miller
From: Steve K Speicher/Raleigh/IBM at IBMUS
To: oslc-pm at open-services.net
Cc: James Conallen/Philadelphia/IBM at IBMUS
Date: 11/30/2012 03:48 PM
Subject: [Oslc-pm] Review of PerfMon spec
Sent by: "Oslc-Pm" <oslc-pm-bounces at open-services.net>
Jim Conallen and I have reviewed the Performance Monitoring 2.0 (dated Nov
28 [1]) and some related documents
This review is NOT a review from the Core WG, though we are 2 Core WG
members who decided to provide some feedback.
Sorry these are in no particular order. Some are nit picky and some may
have a bigger impact:
4. If other query syntaxes are supported, how does the client know what
they are? The OSLC Core provides no guidance on query syntax other than
simple query. There are a number of things a PerfMon provider may do, not
sure it is worth listing all. Recommend getting rid of that MAY section
altogether.
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.
(John Arwe) 6. 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."
(John Arwe) 8. 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.
9. #Reporting-Issues-on-the-Specification The Issues link is to a
non-existent page.
10. In the sample the property dcterms:date is used, and in the spec it is
specified as xsd:dateTime. In the sample it is not typed, and looks like a
string.
12. #Performance-Monitoring-Specification-Guidelines Recommend that the
Guidelines section either provide a lot more useful information or pull it,
as it does not seem to provide much useful information. We couldn't make
much sense out of how it would be applied and there are two sections that
are empty
13. #Appendix-B.3A-Resource-Shapes Shapes appendix is empty.
14. #Intellectual-Property-Covenant The patent non-assert document is
missing or unlinked
17. Mixture of formatting issues: MUST/MAY/SHOULD not always BOLD, etc
19. Why are last 2 of 4 scenarios in table have no data in table?
http://open-services.net/wiki/performance-monitoring/Performance-Monitoring-Scenarios/#Current-Iteration-Scenarios
20.
http://open-services.net/wiki/performance-monitoring/Scenario-Coverage-Report/
missing business goal like other scenarios (or some intro upfront text)
21. #Terminology definition of PMR is quite thin, be good to pull up some
of the text from the more detailed PMR definition like "This could be
numeric metrics, status, or some other kind of property of interest to
monitoring consumers."
24. #Performance_Monitoring_Record
(John Arwe) rdf:type -- at least should include
perfmon:PerformanceMonitoringRecord, right?
ems:observes -- read the description a couple times and still not sure I
get it.
...about a resource “EMS” -- what is *resource EMS*? This is a
formatting issue. The intent was that you read "Something observed and
measured about a resource" and then you can click on the EMS link to be
taken to the related text in the EMS spec.
...MAY be of any type Core -- what does it mean to be *of any type
Core*? Same as above. The intent is that you read "MAY be of any type" and
then click on the Core link to take you to the relevant part of the Core
spec.
When it refers to "the resource" talking about the subject or object
resource? The object ems:Metric pointed to by the ems:observes predicate.
(John Arwe) 25. #Resource.3A-ems.3AMeasure The Turtle example has a weird
trailing ; and then ., suggest removing the ;. There is an unneeded
comment "# rdf:type". Note: the turtle samples in the appendix have the
same problem. It would be good to add the @prefix definitions to make it a
valid Turtle doc.
26. #Metric-Categories consider Turtle example. Also RDFS is used and not
defined.
27. #Resource-Properties
pm:mobilityEnabled -- the description had me wanting more. I'm mobile,
would I be a valid value for this property? Not sure what "move about
dynamically" means. In the sense that a virtual machine can move by virtue
of support in the hypervisor platform.
pm:availabilityStatus -- "All values present MUST be semantically
compatible" how do I know if I do or don't conform to this?
[1] -
http://open-services.net/wiki/performance-monitoring/OSLC-Performance-Monitoring-Specification-Version-2.0/revision/1321/
Feel free to contact us with any clarifications needed.
Thanks,
jim conallen
Steve Speicher_______________________________________________
Oslc-Pm mailing list
Oslc-Pm at open-services.net
http://open-services.net/mailman/listinfo/oslc-pm_open-services.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-pm_open-services.net/attachments/20130102/255ce316/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-pm_open-services.net/attachments/20130102/255ce316/attachment.gif>
More information about the Oslc-Pm
mailing list