OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

provision message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Comments on Draft 8 of the Spec...


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.

 

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.

 

 


Jeff Bohren

13577 Feather Sound Drive, Suite 200, Clearwater, FL 33762

tel: 727.561.9500 x219

fax: 727.374.0171

Jeffrey_Bohren@bmc.com

www.bmc.com

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]