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

[Jeff Parham <jeffparh@windows.microsoft.com>]

Thanks for putting this all together, Christine.  I spent a few hours to
make an editing pass over the document -- details below.  Nothing
controversial intended here -- mostly just minor cleanup to bring some
of the lingering original baseline text forward to sync up with the
changes we've made over the past few months.

Attached are two copies of the result -- the "real" one I'm submitting
for review (dsmlv2-draft9-jp.doc) and the one that I've used Word's
Compare and Merge feature against (diffing against draft 9) and saved
(dsmlv2-draft9-jp-diff_from_draft9.doc).  Please treat the latter only
as a hint to where the changes are -- sometimes Word doesn't do a very
good job with its diff function, and unfortunately I didn't just use
change tracking.

1. Removed various lingering claims that we re-use DSMLv1 encoding.
Alterations we made to the ways object classes are represented, values
are encoded, and other changes mean our encodings of searchResultEntry
elements, etc. no longer look like DSMLv1.

2. In the statement, "Certain error conditions are detected by the
provider without any necessary interaction with a server," changed "are"
to "MAY be."  In some implementations there might be no provider - i.e.,
no DSMLv2-aware code other than the client application itself.  In such
cases (or even when there is such code on the client), it seems
acceptable for the server to detect and to respond to such errors.

3. Moved the "server = program or server" footnote to the body at the
end of section 2, as just prior to that is the definition of "provider"
which references "server."

4. Slightly re-organized section 4 (Top-Level Structure) so as to give
request-response association (positional vs. RequestID) its own
sub-section and to ensure that concepts weren't introduced before any
dependent concepts had been defined.  In doing so, moved
processing="parallel" + responseOrder="unordered" discussion to the
Parallel processing sub-section.  Also cleaned up a couple of pieces of
lingering text that stated that positional correspondence was always
used.  No content changes here, just an attempt to make the concepts
flow a little easier to those readers who haven't been along for the
ride with us in the TC.

5. It seems appropriate to allow future bindings the flexibility to
define which top-level elements they support (be they DsmlRequests, some
new XML envelope, or what have you) and what their semantics are (except
for those that use BatchRequest/BatchResponse, which must necessarily be
well-defined for use by the normative bindings).  Therefore, changed
explicit references to DsmlRequest(s) and DsmlResponse(s) to "requests"
and "responses" (i.e., to reference the individual elements rather than
the one grouping we've defined) except in section 8, where the
requirements for future bindings are defined.  

6. Fixed a few places in the spec to match the latest schema with
respect to the names of extendedRequest, searchRes*, LDAPStatusCode,
etc.

7. Standardized DSML references to be DSMLv1 or DSMLv2 (i.e., changed
references DSML 2, DSMLv2.0, DSML, etc.).

8. Removed lingering note that if present in a document the
errorResponse element is the last element.  (This was true in the
baseline proposal when errorResponse was used solely for syntax errors.)

9. Removed lingering statements that controlValue and extendedResponse
are always base64-encoded.

10. Italicized various element and attribute names.  (Some were
italicized in the text and some were not.)

11. Adjusted reference to VLV (virtual list view) and added
corresponding entry in the bibliography.  Worth noting is that the
existing Internet draft has expired -- an updated draft (for last call)
is pending publication (ETA 3 weeks) at which point we should update
this reference.  I'll take it as an action item to forward the updated
URL when it's available.

12. Removed a couple of lingering references to batch.xsd.

13. Removed some hard line breaks (left over from email, no doubt).

14. Changed SOAP section to state that only the file URI type is
supported.  I believe this is what we agreed upon, for the same reason
that the file binding is restricted to the file URI type (i.e., due to
challenges in determining what security credentials are used to resolve
the URI for various protocols/servers).

15. Cross-bred the URI statements in the SOAP and file binding sections
to ensure both made all the relevant statements on where URIs are
evaluated, what security context is used, what happens when the URI
cannot be resolved, etc.

16. Added "unresolvableURI" to the type attribute value enumeration in
the ErrorResponse element (as referenced in the spec).  (Was already
present in the schema snapshot spec, just hadn't yet made it to the
XSD.)

Thanks,
-J

-----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

DSMLv2.xsd

DSMLv2-draft9-jp.doc

DSMLv2-draft9-jp-diff_from_draft9.doc