Re: [provision] PSO elements and returnData option.

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

Discussed this with Jeff Bohren, and we propose to:

1) Remove the 'none' option (i.e., delete the 'none' value of 
ReturnDataType).

2) Define the rest of the values (of returnData) as follows:
    - "identifier": return any number of <pso> elements,
       each of which contains only the <psoID> subelement.
    - "data": return any number of <pso> elements,
       each of which contains only the <psoID> and <data> subelements.
    - "everything": return any number of <pso> elements,
       each of which is fully loaded.

This would require changing the XSD to make the <data> element in 
PSOType optional (i.e., minOccurs=0).

Does anyone object?  Does this cause heartburn for anyone?

Gary P Cole wrote:

> I agree that returning empty <psoID> elements (and empty <data> 
> elements) is pretty bogus.
> However, the XSD states that these elements are required.
>
> ReturnDataType is used in two places: lookup and search. Neither of 
> these operations really needs a 'none' option. I remember we had a use 
> case for <lookupRequest returnData='none'> as a pure existence check, 
> but returning a (possibly unwanted) <psoID> won't cause any harm.
>
> However, we still have the problem of an empty <data> element when 
> returnData='identifier'.
> Should we also eliminate the 'identifier' value of ReturnDataType?
> Or should we make the "data" element of PSOType optional?
>
> Bohren, Jeffrey wrote:
>
>> 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.
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all your TCs in 
> OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php