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

 


Help: OASIS Mailing Lists Help | MarkMail Help

dsml message

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


Subject: RE: [dsml] Draft 9 11/06/01


Thanks Christine.

There are a few inconsistencies between the spec and xsd:

(1) The spec says the result should be in the form:
<resultCode descr="success">0</resultCode>
 
but the schema says it should be:
<resultCode code="0" descr="success"></resultCode>
 
 
(2) According to the spec, the attributes to be returned in a
searchRequest are specified as:
<attributes>
<attribute>cn</attribute>
</attributes>

But, according to the schema, it's specified as
<attributes>
<attribute name="cn></attribute>
</attributes>
 
 
(3) According to the spec, controls are specified like:
<searchRequest .....>
   <filter>.....</filter>
   <attributes>.....</attributes>
   <control type="1.2.3">....</control>
</searchRequest>
 
But, because of the way the schema derives the request types from a
DsmlMessage base type, it says: (notice the sequence)

<searchRequest .....>
   <control type="1.2.3">....</control>
   <filter>.....</filter>
   <attributes>.....</attributes>
</searchRequest>


(4) Need some clarification:  searchResponse, searchResultReference,
searchResultEntry, and searchResultDone can all have a requestID
associated with them.  This raises the question of, if one sends a
searchRequest with a requestID attached, when DSML Gateway/Server
generates the response, to which of the search response elements should
the requestID be attached to?  Just the searchResponse?  All of them?
The spec doesn't say, and semantic issues aren't covered by the schema.




Thanks
-andy

-----Original Message-----
From: Christine Tomlinson [mailto:chris.tomlinson@sun.com] 
Sent: Monday, November 05, 2001 5:17 PM
To: DSML version 2
Subject: [dsml] Draft 9 11/06/01

Attached is the current draft and schema. Changes:

1) Added '9. Bibliography'
2) capitalized all appropriate occurences of MAY, MUST, etc.
3) section 5. fixed batchResponse to batchRequest in first example (per
Siva Kumar 10/22)
4) fixed occurence of searchResultRef to searchResultReference in 5.3
(per Siva Kumar 10/22)
5) changed spelling of extendedReq/Resp to extendedRequest/Response in
schema and text 5.8 (per Siva Kumar 10/22)
6) corrected DSMLBatchResponses to BatchResponses (per Prasanta 11/01)
7) corrected occurence of 'name' attribute in searchRequest example
section 5.2 (per Nigel 11/02)
8) cleaned up section "4. Top-Level Structure" to use
DSMLRequests/Responses in accordance with schema. If the group wants to
remove text entirely then we can do that at telecon (per Rob 11/02 and
Jeff 11/05)
9) changed Bind to Auth. If the group wants to make the name longer
(Authorization) fine. I thought that perhaps the shortened form would be
fine but am easy on this one (per Rob 11/02 and Jeff 11/05)
10) declined to alter structure of BatchResponse (per Rob 11/02 and Jeff
11/05) - If the group decides to go with Rob's proposal will fix in next
draft.
11) corrected title of "8. Extensibility Guidelines" (per Rob 11/02)
12) added text to security statement in "6. SOAP Request/Response
Binding" (per Andy 11/05)

ciao,
Christine


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


Powered by eList eXpress LLC