| |
Comment: |
Karl's comments on these items:
...
> >8) page 23: I consider it inappropriate to have the last part of the
> >sentence "PortTypes of this sort are in error and the designer should be
> >ridiculed." in an official spec.
> >
I agree.
> >9) page 25: I am unsure if I understand what is meant by: "However,
> >clients and services MUST accept and act appropriately on messages
> >containing time values that are out of range due to inadequate
> >synchronization, where "appropriately" MAY include refusing to use the
> >information associated with those time values."
> >Does "accept and act appropriately" mean that "when out of range times are
> >detected for whatever reason, client and servers MUST treat this as an
> >error condition"?
> >
No, we did not want to make such a strong statement. The goal is to
encourage robust system behavior in the face of desynchronized
clocks. Many of us believe that the suggested "MUST treat this as an
error condition" above would actually lead to a more fragile system.
It is feasible that the semantics of a particular portType could allow
more sophisticated compensation techniques to avoid determining an
error condition. For example, in the Factory portType, we were careful
to return both the service's belief in the creation time as well as
the termination time of the newly created service. This means that
the createService operation results are well-defined even if the
creation time appears to happen far in the future or past by the
client's clock.
> >10) page 25: "Zero time SHOULD be represented by a time in the past or by
> >the string "now." "
> >means it is possible to subtract two zero times and end up with a finite
> >time interval. Is that a problem?
> >
That expression is meant to placate people who (as a hack) use a
notion of zero time in existing designs which they want to map to
OGSI. I think it should be "could" rather than "SHOULD".
Even postulating a "zero time" is rather metaphysical... are there
"negative times" or "negative infinity time"?
Realistically speaking, a zero time is really an agreed upon
interpetation of the beginning of an epoch for system components. The
Grid may federate many such systems, each with its own agreed upon
zero time. Components in those systems should always use the same
zero time, so this non-zero difference would only occur when
introspecting on the difference between different community standards.
It SHOULD never occur in practice that a zero time from one community
gets delivered with the intention of being interpreted as a zero time
in another community. Whatever entity is mediating between the
communities SHOULD be remapping between whichever times are locally
considered zero.
> >11) page 25: in fact the terms zero time and infinite time are badly
> >defined. What is meant, an absolute time point or an interval.
> >Should be corrected because if these values are to be used late for
> >accounting purposes, the definitions should be precise.
> >
I agree, zero time is a non-concept. Infinity is meant specifically
for negotiating open intervals.
It would make no sense to ever have an accounting record of something
happening at zero time or at infinity time. The use of infinity time
as a "terminate before" time expresses indeterminate expectation of
service termination. However, the use of infinity time as a "terminate
after" time expresses the same thing as far-flung future dates: the
service is expected not to terminate in the forseeable future.
> >12) page 30: should the SHOULD's in 751 not be MUST's?
> >
That would not bother me, and I was the one who stuck those
requirements in. I was afraid to use MUST in case that would cause a
veto of the requirements, based on some expected mapping of GSR to
existing technology that I do not understand. ;-)
> >13) on page 31: "A GSR is valid when the associated Grid service instance
> >exists and can be accessed through use of the Grid Service Reference, but
> >validity MAY only be detected by the client attempting to utilize the GSR. "
> >
> >This MAY means desirable. I can interpret this as there are possibilities
> >that the client can not detect the (in)validity of the GSR, correct?
> >However, maybe far fetched from me. I would phrase: ", but validity MUST
> >be detectable by the client...."
> >
I'm not sure I understand the comment. I think that the spec. text
could have been better phrased as:
invalidity MUST be detectable by a client attempting to utilize the
GSR, while it MAY be detectable by other means for certain GSR schemes.
The difficulty with all such text is that "validity" is really an
interpretive notion not possessing clear boundaries. One situation's
invalid GSR might be another's transient binding error.
> >14) page 31: I guess the working group went over this: "Use of an invalid
> >Grid Service Reference by a client SHOULD result in an exception being
> >detected by or presented to the client. "
> >
> >why not MUST?
> >
I do not remember precisely, other than as in my comment above for
(12)... it seems like somebody else in the group had mappings in mind
where some of these things might be violated?
...
> >16) page 34: "If the requested termination time is before the current
> >time, then this SHOULD be interpreted as a request for immediate termination."
> >
> >Should this SHOULD not be a MUST? Otherwise the service could remain to
> >exist continuing to incurr costs to the client.
> >
If a MUST, I would want it to read "as a request for immediate or
prior termination" to allow an accounting compensation where the
service back-dates the termination and the client does not even incur
costs for the time between the requested termination and the actual
termination. That is the direction of openness I believe we were
trying to protect with the SHOULD, though I agree it seems
unfortunately to have allowed non-termination as well.
...
> >18) page 36: "All faults from a Grid service SHOULD either use this type
> >directly, or extensions of this type. "
> >
> >SHOULD --> MUST ? or can they choose another type also?
> >
I think this is a very interesting question to resolve. I think other
top-level fault types are allowed. What is the semantics of such a
fault? Do we believe that the specification REQUIRES Grid faults to
have any uniformity of meaning (not uniformity of content), e.g. is a
fault always understood to signal a non-effecting invocation? Or is
a fault semantics really up to each portType?
> >19) In 9.2.3-9.2.4 also specify "now"
> >
> >20) page 47: 9.2.5 "MUST either initiate its own destruction and return a
> >response acknowledging "
> >
> >change "either" in "both"
> >
I do not undertand this comments intent, nor do I see any problem with
the text on re-reading it?
> >Sure that the SHOULD in "Once destruction of the Grid service is
> >initiated, the service SHOULD NOT respond successfully " is not a MUST ?
>
Some of us do not care to over-restrict the function of services
"during" termination. For example, is it necessary that a
findServiceData query fail during this time?
karl
|
