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: RE: [provision] Request attendance for the Tue con call...


Thanks for all these good comments. See comments below.

Jeff B.

-----Original Message-----
From: Gary.P.Cole@Sun.COM [mailto:Gary.P.Cole@Sun.COM] 
Sent: Monday, May 21, 2007 8:09 PM
To: Bohren, Jeff
Cc: provision@lists.oasis-open.org
Subject: Re: [provision] Request attendance for the Tue con call...

Jeff, I have a few questions/comments about the Errata.  (I apologize if

I'm asking questions that were covered at the Face-to-Face: I'm working 
strictly from the document.)

2.3) If we change MUST to MAY, will we clarify the role of 
ReturnData.NOTHING?  For example, if successful, the response MUST 
contain a <pso> element UNLESS the request specified

2.4) The core XSD that is part of the Oasis Standard 
(pstc-pstml2.0-os/xsd/pstc_spmlv2_core.xsd) does not define 
ReturnData.NOTHING.  Would you add "nothing" to this XSD file (as well 
as to Appendix A)?

For that matter, do we really need ReturnData.NOTHING?  It might be 
simpler to remove the four references to ReturnData.NOTHING (add:1560, 
lookup:1696, modify:1835, and search:3365).  The last reference looks to

be erroneous, anyway (see my next comment below).

*NEW*)  The discussion of the ReturnData within Search Request was 
copied from the AddRequest.  It says "added object" where it should say 
"selected object" (on lines 3367, 3369, 3371 and 3374).  Also, I don't 
think that the reference to ReturnData.NOTHING (on line 3367) makes 
sense for the Search Request.  Why select objects if you want nothing

[JSB] We should revisit this issue on the next call and decide what we
really want to do about this one. I would prefer not to fix any errata
that would cause even an editorial change to the XSD, but we are
constrained by the requirement that the errata can not make any
significant change to the spec.

2.5) Why should the psoID element in the password requests included the 
prefix of the password capability?  Why would the psoID not have the 
prefix of the core xsd?
(Same questions in 2.6 and 2.7.)

[JSB] This is because the XSD included the psoID element definition in
the password capability, rather than leaving it to the open content
model to allow the code psoID element to be included. 

2.7) Line 4112 refers to the "timestamp" attribute.  I think you mean 
line 4108, which refers to <psoID>.

[JSB] I will fix this in the next draft.

2.8) How would you clarify section to be consistent with 
regard to the namespace for Search?  The Errata draft doesn't say.

2.9) In the corrected example Add Response, shouldn't <pso> be 
<spml:pso> (that is, prefixed to match the other elements)?

[JSB] I will fix these in the next draft.

2.10) Same as 2.9.

2.11) Same as 2.9.

Bohren, Jeff wrote:

> On the Tue Con Call I would like to vote on the errata items in the 
> latest draft of the document. If you are a voting member please try to

> attend this call. I have attached the latest draft document for your 
> convenience.
> *Jeff Bohren*
> 13577 Feather Sound Drive, Suite 200, Clearwater, FL 33762
> tel: 813.433.5719
> Jeffrey_Bohren@bmc.com <mailto:Jeffrey_Bohren@bmc.com>
> www.bmc.com <http://www.bmc.com>
> Blog: http://talk.bmc.com/blogs/blog-bohren/jeff-bohren/

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