Re: [provision] Comments on Draft 8 of the Spec...

[Gary P Cole <Gary.P.Cole@Sun.COM>]

Bohren, Jeffrey wrote:

> 3.5.1.4.3 – The modification element in the modify example doesn’t 
> look right. It is:
>
> <modification modificationMode="replace">
>
> <component>/Person/email</component>
>
> <data>joebob@example.com</data>
>
> </modification>
>
> But I think it should be:
>
> <modification modificationMode="replace">
>
> <component namespaceURI="http://www.w3.org/TR/xpath20"; 
> path="/Person/email"/>
>
> <data>
>
> <email>joebob@example.com</email>
>
> <data/>
>
> </modification>
>
> The point being that to replace a subelement of PSO data, you must use 
> an XPath to identify the subelement to be replaced. Also, the 
> modification is limited to an XML element, not the value of an element 
> of attribute.
>
Spec issue #41. Same fix to bulkModify example in 3.5.4.1.

> 3.5.3.1 – remove the XSD annotation from the BatchRequestType and 
> BatchResponseType. I will remove them from the XSDs as well. Also 
> change *A batch is not a logical unit of work* to *A batch does not 
> need to be a logical unit of work*. We need to rework this paragraph 
> to convey that a batch may or may not be a logical unit of work, but 
> if it is, that is outside the bounds of the spec. The way it is 
> written implies that it can not be a logical unit of work.
>
> Also there is a section that refers to *BatchableRequestType*. This is 
> no longer a type defined by SPML 2.0.
>
> 3.5.4.1.3 The bulk modify example is incorrect. Should match the 
> changes to the modify example above. Also the modify for capability 
> data looks funny. I don’t know if we ever really figured that part 
> out. Could you mark this as an issue to be resolved?
>
> 3.5.6.3 The RACF examples in this section need to be moved to an 
> explicitly non-normative example section. In particular the XSD for a 
> “RacfGroupMembershipType” seems to imply that this is part of the 
> reference capability itself rather than an example of the usage of the 
> reference capability.
>
> 3.5.7.1 The text (at line 2556) incorrectly states that if the search 
> criteria matches no PSOs, that the search response should return an 
> iterator of with a count of 0. If the search criteria matches no PSOs, 
> then a search response with no PSOs should be returned. An iterator is 
> only returned when there is further data to be retrieved.
>
> 3.5.7.1.2 Line 2649 states that if a PSO ID element must always be 
> present, then it states that if return data is specified as none, then 
> the PSO ID element would be empty. That would result in N number of 
> identical PSO ID elements, which wrong to me. I don’t see what that 
> would accomplish except being a very expensive way to do a server side 
> count. I would like to remove the none option completely.
>
> On line 2661 we state that if the option is none or identifier only 
> then the data element should be empty. That is not correct. In this 
> case the data element should be omitted. An empty data element should 
> never be present.
>
> 3.5.7.1.3 The example on 2735 is incorrect. An iterator is never 
> returned in all the data in response to the search request is 
> contained in the search response. The iterator is only returned to 
> enable a subsequent request to retrieve the rest of the data. If not 
> subsequent request is needed, an iterator is not needed.
>
> 3.5.7.2.2 Same comments as for 3.5.7.1.2.
>
> 3.5.7.2.3 The iterate request example on line 2897 should not pass 
> back the count or total count attributes. Just the ID is needed.
>
> Also in line 2989 and the subsequent examples, searchResponse should 
> be changed to iterateResponse. The count attributes in the examples 
> are not correct. The count should be the number of entries that the 
> next iterate request will return, where the total count should be to 
> total number of entries. In this example the count attributes should 
> be one. I think this example would work better if each request fetched 
> the next two PSOs rather than one at a time.
>
> 3.6 I would remove the “registry” stuff on line 3097. This falls into 
> the “If a frog had wings…” category.
>