Re: 1 or 2 XSDs

[Christine Tomlinson <chris.tomlinson@sun.com>]

1) DsmlRequest/DsmlResponse are indeed not elements they are choices of
elements ALL of which MUST be supported by ALL transport bindings.
2) the BatchRequest/BatchResponse are not likely to be the foundation
of a next transport binding; however, the DsmlRequest/DsmlResponse are
since BatchRequest/BatchResponse are NOT required of ALL transport bindings
whereas the elements defined in the choices DsmlRequest/DsmlResponse are
required in ALL transport bindings.
3) The technical justification for distinguishing between the DsmlRequest/DsmlResponse
elements and the particular BatchRequest/BatchResponse envelopes is that
technically DsmlRequest/DsmlResponse elements are required in ALL transport
bindings whereas the particular BatchRequest/BatchResponse elements are
NOT required in ALL transport bindings.

ciao,
Christine

Jeff Parham wrote:

 By that logic I would expect your proposal to be for 3 schemas ("core", DsmlRequest/DsmlResponse, DsmlEnvelopeRequest/DsmlEnvelopeResponse) rather than 2 -- DsmlRequest/DsmlResponse clearly are not elements that must be supported by all transport bindings.  And one could argue that DsmlEnvelopeRequest/DsmlEnvelopeResponse are just as likely to be the foundation of the next transport as are DsmlRequest/DsmlResponse.In any case, I don't see any technical justification for trying to draw "fundamental" vs. "non-fundamental" delineations in the DSMLv2 grammar.  My vote is for a single schema.Thanks,-J

-----Original Message-----
From: Christine Tomlinson [mailto:chris.tomlinson@sun.com]
Sent: Tuesday, September 25, 2001 4:24 PM
To: Jeff Parham
Cc: dsml@lists.oasis-open.org
Subject: Re: 1 or 2 XSDs
 

The motivation is to clearly separate those elements that must be supported in any transport binding from the specific set of enveloping elements used in the SOAP and File transport bindings. The motivation does not include concern for burdens on the client since there is none either way. This is not offered as an optimization. There is no advantage to a single schema that then has elements that are not used in future transport bindings. The two schema proposal provides a clean and simple prototype for how to define new enveloping elements for new transport bindings. I have not seen a clear and compelling case as to why we should not define DSML v2 in such a way as to promote future development. There is no cost to doing so.

ciao,
Christine

Jeff Parham wrote:

I'd like to see us stick to one XSD.The motivation for 2 XSDs seems to be that it might be burdensome for the DSMLv2 client/server to consume additional schema that it will not use.  If that's true, then if we were going to optimize the number of XSDs wouldn't we optimize such that DSMLv2 clients and servers that implemented the "standard" transports would need only one XSD (that defined just what was needed for envelopes), rather than optimizing for possible future transports?I don't see any real reason to pursue that path, however.  Given the small amount of schema that is unique to either DsmlEnvelopeRequest/DsmlEnvelopeResponse or DsmlRequest/DsmlResponse it seems prudent to simply define a single XSD for DSMLv2.Thanks,-J