[ogsa-rss-wg] [ogsa-wg] Resource Selection Service Specification, Draft 5

[Hugo Mills]

   Donal - 

On Tue, Aug 14, 2007 at 02:08:59PM -0700, Donal K. Fellows wrote:
> I'm happy to announce that the fifth draft of the RSS specification is
> now available. I've fixed most of the critical issues; those that are
> left are really editorial things (e.g. fixing up references).
[snip] 
> If there's anyone who hasn't received this message that you think needs
> to read it, please forward it to them. (But don't go silly; it doesn't
> need to be a full-blown Internet Chain Letter...)

   Just a few comments, mostly minor (and apologies if any of this has
been covered before). I'm using section/para numbering, because I'm
not 100% certain that the line numbering will be the same across
systems.

Section 4.2, para 2 refers twice to "CSG renderings". It took me
several goes to work out that it was referring to an XML document
describing the schema for documents accepted & generated by an
implementation of the service. I'm not sure how this could be
clarified, though.

Section 4.2.1, para 2 states "The CandidateOrdering element MUST have
a dialect element...". Surely this should be "... a dialect
attribute..."?

Same sentence as above, the word "arbitrary" should probably be
deleted -- it reads like the URI could vary arbitrarily and still
somehow describe the same content type.

Section 4.2.1, para 3, last sentence: could possibly clarify that a
Candidate MUST NOT generate an extension element if there is no
corresponding PermittedCandidateExtension element in the request.

Section 4.2.2, para 1, last sentence: add the word "document" after
"RequestCandidates".

Section 5, para starting "Note that a Basic-EPS...": Possibly reword
"This list of ways of variation is not intended..." to "This list of
variations is not intended..."

Section 5.1.1, para 2: It may be better to describe it such that the
estimated cost is bounded below by the sum (after appropriate currency
conversion) of the minimum values of each PriceRange element, and
bounded above by the sum of the maximum values of each priceRange
element.

Section 5.1.1, para 5: Clarify that having no Prices element MUST NOT
be interpreted as having zero cost.

Section 5.3, para 2: After "... the italic elements are those that
are...", add the word "required".

Section 6.2.1, para 3: This is a complete copy of the earlier
definition of the same element, section 4.2.1, para 2. Would a
reference to the earlier definition be better here?

Section 6.2.1, para 6: IterableSetLifetime is defined to have
XML-Schema time duration type. Everywhere else (eps-basic:StartDelays,
eps-basic:ExecutionDuration), the durations are specified in seconds
as floats. This seems inconsistent.

Section 6.2.1, para 11: UnsupportedOrderingFault MUST NOT be thrown if
the Ordering [surely, CandidateOrdering?] contains a valid SCOL
document. Therefore, I could specify:

<CandidateOrdering dialect='needle:nardle-noo'>
   ... valid SCOL...
</CandidateOrdering>

This then implies that the service implementation MUST ignore the
supplied dialect, and attempt to parse the ordering document as SCOL
before throwing this fault. I would suggest specifying that the fault
MUST NOT be thrown if the dialect is SCOL, and the CandidateOrdering
contains a valud SCOL document.

Section 7.2: (The controversial one) Is there a reason why this isn't
specified as a subset of MathML? It would seem to be a good fit.

If MathML isn't going to be used, then I would suggest that
<Difference> and <Quotient> be added for convenience -- yes, you can
implement them with <Negate> and <Power>, but it strikes me as
minimising the set of elements simply because it's possible, rather
than for good implementation reasons. People will expect to see
<Difference> and <Quotient>, and jumping through additional hoops to
get them is bound to seem a bit odd.

   Hugo.

-- 
Hugo Mills <hugo at soton.ac.uk | hugo at omii.ac.uk>
OMII-UK, Southampton, SO18 1NP, UK