[GSA-RG] CandidateQualityProperties

[Donal K. Fellows]

[Sorry for not replying sooner; I've been stuck offline for a few days.]

Philipp Wieder wrote:
> I would just say that there are cases where the existing CQP elements
> will not fulfil the requirements people have. As in our case (which is,
> for the time being, not really "advanced", but just a bit different),
> where we just have different requirements concerning the "how long it
> will take" attributes.

While I'm sure that there are cases that are not covered, it's difficult
to respond in any meaningful way when the current difficulties are not
described in detail. (A link to the right place in GridForge would be
the most helpful and succinct way of doing this, of course. :-))

> Our intention is to achieve interoperability
> between schedulers and we would like to use a some description for the
> scheduling related attributes (or QoS, if you want).

I suspect this is likely to be a problem in deployment BTW. A
significant number of people that I've talked to only want to describe
QoS in terms of "Bronze/Silver/Gold Service Level" and leave it at that.
How they expect anyone to analyse such a horror (without vast amounts of
Semantic Grid goop in the way) I really I don't know. But I digress.

> And we would like
> to ship it together with an EPS request as well as WS-Agreement, e.g,
> therefore we think going for something which can live in both (and
> potentially other) specs would be good. But as you said, there is an
> extension point. The only problem for us is, that the CQP elements are
> mandatory for the EPS case and will collide with our time-related
> attributes ...

I have a couple of points to make. The first is that I still think you
can't get more than an agreement template out of anything matching a CSG
since I think it is unwise to cede the right to conclude an agreement to
a candidate set generator. After all, it's going to be (potentially)
returning a great many of the things and you don't want to be tied up in
that many contracts. :-)

The second is that strictly reading the spec (i.e. draft 7) I see that
they can all be omitted and you can substitute your own CQP terms, so
long as they are not semantically the same. The fact that you're wanting
to do it indicates that there probably is a mismatch and so it's not a
big problem. And I don't actually normatively state that the semantic
distinction must be there, but you need to be a spec-language-lawyer to
spot that point. :-) (The beginning of the paragraph says that the
standard attributes must be supported, but does not state exactly what
this means; I use a JSDL-like interpretation of the phrase, in that
supporting the element does not mean that it ever needs to appear.)

To nail the point home, this is a valid CQP, even according to the EPS
rules (and not just the CSG rules[*]):

   <csg:CandidateQualityProperties>
      <airline:FrequentFlierLevel> Gold </airline:FrequentFlierLevel>
      <airline:ScheduledTakeOff> 10:20 </airline:ScheduledTakeOff>
      <airline:ScheduledTouchDown> 12:45 </airline:ScheduledTouchDown>
      <airline:Baggage> Lost! Hahaha! </airline:Baggage>
   </csg:CandidateQualityProperties>

Not to imply that this is an offer you'd necessarily want to use. ;-)

If I'm misunderstanding, tell me how. :-)

Donal.
[* What the EPS rules do is define some common element meanings. They
    don't restrict general expressiveness. ]