> From: "[email protected]" <[email protected]>
> To: [email protected]
> Cc: [email protected]
> Sent: Friday, January 4, 2013 4:52:05 AM
> Subject: Re: CIMI test plan - resource metadata
>
> On 04/01/13 01:28, [email protected] wrote:
> > First draft of the Resource Metadata Test Plan (including xsl file)
> > - Machine capabilities: DefaultInitialState and InitialStates
> >
>
> TL;DR: I think I'll go ahead and push this and you can tweak/fix the
> following points as you see fit
Marios, thanks for the review - comments added in line ...
>
>
> Hi Ronelle:
>
> this is looking very good indeed. Couple minor comments/points of
> clarification:
>
> * Part1 => 1.2 => Success Criteria : "For each collection appearing
> in
> the CEP there should be a ResourceMetadata entry with the
> corresponding
> typeURI in the ResourceMetadata collection "
>
> =====I'm not sure if this is true; it is my understanding that there
> will be entries in the Resource Metadata Collection for those
> Resources
> that the Provider wishes to advertise some feature/capability/action.
> Did you find something in the spec to the contrary which I (very
> well)
> may have missed?
I added this extra assert from a comment David sent as part of the first plan
review (copied below). David, can you confirm that this is still a test point
we can to assert on?
* 1.2: we should assert that for each collection appearing in the
CEP there is a RMD entry with the corresponding typeURI in the
RMD collection
>
> * Part 2 "This test only applies if CEP.machines is present"
>
> ======I think this should be "only applies if CEP.ResourceMetadata
> collection contains an entry corresponding to the Machine resource"
> (follows from my first point above)
Fixed - the note now reads:
This test applies only if the CEP.machines collection is present and the
CEP.ResourceMetadata
collection contains an entry corresponding to the Machine resource.
>
>
>
> * Parts 3/4 - need a "only applies if the ResourceMetadata resource
> corresponding to the Machine resource contains a _name_ capability"
> (i.e. _name_ is [DefaultInitialState | InitialStates] )
>
Fixed - added notes to Tests 3 and 4.
>
>
> * This one is a bit nick-pickingy - just a thought: Part2 => 2.1 =>
> Success Criteria: "Capabilities, attributes and actions available on
> the
> provider that are associated with the Machine collection must be
> listed"
>
> =====I think we might tweak the wording a bit here; something like
> "at
> least one of capabilities/attributes/actions must be listed within
> the
> Machine Resource Metadata resource". For two reasons: first to
> clarify
> that a RM resource doesn't have to have all three (I know this isn't
> what you meant, but it might be read that way), and explicate that if
> there is a RM resource for a collection FOO, it must advertise at
> least
> *something* there (i.e. feature and capabilities and actions are ALL
> optional; but at least one of them should be listed otherwise there's
> a
> problem with that RM resource).
Fixed - At least one of capabilities/attributes/actions must be listed within
the Machine Resource Metadata resource. Note that a Machine Resource
Metadata resource does not have to have all three
(capabilities, attributes and actions) necessarily, but at least one
capability/attribute/action must be returned.
>Secondly, since this is 'success
> criteria' it must be verifiable; "available on the provider" - how
> are
> we going to verify that? I mean, you get a list of RM capabilities,
> how
> do you know it includes all those that are 'available'.
Good question - The assumption is that test writers will be able to find out
what capabilities/attributes/actions are supposed to show up when a certain
provider is under test. I don't have a good, generalized way of verifying
expected capabilities/attributes/actions as they are all optional.
>
>
> marios
>
>
