This is a static archive of the previous Open Grid Forum GridForge content management system saved from host forge.ogf.org file /sf/sfmain/do/go/artf3330?nav=1&selectedTab=comments at Sun, 06 Nov 2022 15:12:18 GMT SourceForge : artf3330: (89) List of small items from Cees de Laat

Project Home

Tracker

Documents

Tasks

Source Code

Discussions

File Releases

Wiki

Project Admin
Search Tracker
Project: OGSI-WG     Trackers > OGSI V1.0 Specification > View Artifact
Artifact artf3330 : (89) List of small items from Cees de Laat
Tracker: OGSI V1.0 Specification
Title: (89) List of small items from Cees de Laat
Description:
This list of items was compiled by Cees de Laat. I have listed them together here so that 
we don't loose them. But I have not tried to assess them or sort them in any way.

>1) page 6: , we define a gwsdl extension to WSDL. This is a temporary 
>measure until WSDL 1.2 is complete
>
>Does this mean that there will be a revision of this doc before it ever 
>can get at full recommendation (from the proposed state)?
>
>2) page 9: GSH -> HandleResolver -> GSR : how does a client know a GSR has 
>become invalid?
>
>Specify how to locate Handleresolver   [THIS IS TREATED IN THE DOC FURTHER 
>DOWN] Maybe just some clarification here.
>
>3) page 12: the statement: "The Global Grid Forum commits to updating OGSI 
>when WSDL 1.2 [WSDL 1.2] is published as a draft specification by the 
>W3C." is a serious one. Why can't we get an equivalent statement from 
>them? Otherwise we may end up having to redo this part of OGSI. This also 
>adds to 1) above.
>
>4) page 12:
>targetNamespace=
>    http://www.gridforum.org/namespaces/2003/03/gridWSDLExtensions
>do we want everywhere gridforum.org to be replaced by ggf.org, also in the 
>namespaces...?
>
>5) page 13: "The following is from [WSDL 1.2 DRAFT]:" means that this text 
>is unstable, may change in the future. I don't know but assume that just 
>as the ietf the w3c forbids or discourages references to draft docs?
>
>from that draft:
>"This is a draft document and may be updated, replaced or obsoleted by 
>other documents at any time. It is inappropriate to use W3C Working Drafts 
>as reference material or to cite them as other than "work in progress". 
>This is work in progress and does not imply endorsement by, or the 
>consensus of,
>either W3C or members of the Web Services Description Working Group."
>
>6) page 14 last sentence: facilitates the execution of operations against 
>the service
>
>Am I correct to replace: against -> on
>
>7) page 20 in 6.2.3: for consistency use MUST NOT or SHALL NOT in the 
>static and extendable spec.
>
>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.
>
>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"?
>
>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?
>
>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.
>
>12) page 30: should the SHOULD's in 751 not be MUST's?
>
>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...."
>
>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?
>
>15) page 33: 7.5.2.1 : Sameness ?? Should this be Semantics?
>
>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.
>
>17) page 35: "(ogsi:ExtendedDateTimeType is defined in �7.2, which allows 
>for the expression of an xsd:dateTime or the special value "infinity".)"
>
>What about the other special value "now"
>
>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?
>
>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"
>
>Sure that the SHOULD in "Once destruction of the Grid service is 
>initiated, the service SHOULD NOT respond successfully " is not a MUST ? .
Submitted By: David Snelling
Submitted On: 05/28/2003 9:12 AM EST
Last Modified: 06/17/2003 7:07 AM EST
Closed: 06/17/2003 7:07 AM EST

Status / Comments Change Log Associations Attachments  
Status  
Group: * General
Status:* Closed
Category: * Proposed Change
Customer: *
Priority: * 3
Assigned To: * David Snelling
Reported in Release: *
Fixed in Release: *
Estimated Hours: * 0
Actual Hours: * 0
issue_type: * normal
resolution: *
Comments
David Snelling: 06/17/2003 7:07 AM EST
  Comment:
Steve made these changes and I have verified. See mailing list for detailed summary: 

Re: [ogsi-wg] [Bug 120] New: List of small items from Cees
Monday, June 16, 2003 0:11
  Action: Update
David Snelling: 06/17/2003 7:07 AM EST
  Action: Update
artifact_status changed from Open to Closed
close_date changed from - to 2003-06-17 13:07
David Snelling: 05/28/2003 9:34 AM EST
  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
  Action: Update
David Snelling: 05/28/2003 9:12 AM EST
  Action: Create


 
 
 
< Previous
 
 
Next >
 


The Open Grid Forum Contact Webmaster | Report a problem | GridForge Help
This is a static archive of the previous Open Grid Forum GridForge content management system saved from host forge.ogf.org file /sf/sfmain/do/go/artf3330?nav=1&selectedTab=comments at Sun, 06 Nov 2022 15:12:18 GMT