On Feb 16, 2003; Dave Snelling did a sweep of inline comments in the document. They 
are included here in case these issues need revisiting in the next version. The items 
thought to be important in v1 have been captured in other actions and v1 bugzillas.

All the comments were then removed from the document.

Comments from Draft 17:

Section 1:

No comments found in text.

Section 2:

No comments found in text.

Section 3:

No comments found in text.

Section 4:

No comments found in text.

Section 5:

No comments found in text.

Section 6: 

No comments found in text.

Section 7.1 - 7.6:

No comments found in text.

Section 7.7: Faults

KC: Is SemanticFaultType meant to cover everything that is not structurual, e.g. violations 
of policy as well as implementation errors or limitations?
   - Deleted when flattening faults.

Section 8: 

No comments found in text.

Section 9.1:

No comments found in text.

Section 9.2.2:

TM: Are any of the servicedata elements on GridService porttype ?updateable??  Any of 
the other spec?d porttypes? 
   - It appears not.

TM: This result works for a by name updateExpressionType.  Not sure about others.
   - The pattern should be the same with others.

TM: Not sure these faults work for any case other than the byName 
updateExpressionType.
   *** Worth discussing.

DS: Are IncompatibleValueType and IncorrectValue the right fault name? AND ST: Clean 
up this language.  What is ?the value??
   - Already an action item.

Section 9.2.2.1:

TM: Example request.
   - Consider in primer or v2.

TM: If the answer to the above comment is MUST then I don?t understand the need here.  
If I faulted then none of the values were written and I don?t need a list of the ones that 
fauled.  Unless you mean that you are sending back an indication of the reason that all 
were not written?..
   - I believe that the answer was not MUST, as no transaction semantics are now implied.

TM: [Last para] So does this mean that the set is coherent but the query is not?
   - Both. The OGSI spec make no general assertions about the coherency of SDEs.

Section 9.2.5:

SG: Email to list about wanting finer distinction in faults.
   - Faults are generally under review and are actioned.

Section 10:

DS: [Faults of FindByHandle] I'm not sure the spec should include these last four faults as 
they imply a level of functionality beyond that of may simpler resolver schemes. If we do 
keep these in, they should be subtypes of NoReferenceAvailable.
   *** Worth discussing.

DS: I'm not sure the spec should include these last four faults as they imply a level of 
functionality beyond that of may simpler resolver schemes. If we do keep these in, they 
should be subtypes of NoReferenceAvailable.
   - Not a critical question. May have an impact from more general approaches in V2.

Section 11.2.1:

SG: [SubscriptionExpression] What is the type of this?  Is it anything more than xsd:Any? 
(pv:) It should probably be at least an element as that is what is passed to subscribe() ? 
similar to ContentEntryType in 13.2.1.
   - Still at anyType. Non critical issue.

Section 12:

DS: This will probably need to go, as I can't see use mandating this strongly, but this 
discussion is still pending. SG: I don?t agree David, I see no reason why this cannot be 
mandated.
   - Section is highlighted for discussion. Delete comment.

Section 12.1:

SG: [CreatesPortTyp] I think this SDE should be removed.  This should be implied by the 
CreatesInputType expressions.  In the future, we will probably want a much more rich 
way of associating input types with output portTypes.
   - Issue in bugzilla and actions on the agenda.

Section 13:

All comments in this section are out of date as the issue is under major discussion.
   - All deleted.
 .