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></data>
>
> </modification>
>
> But I think it should be:
>
> <modification modificationMode="replace">
>
> <component namespaceURI="http://www.w3.org/TR/xpath20"
> path="/Person/email"/>
>
> <data>
>
> <email></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.
>
