RE: 1 or 2 XSDs

[Shon Vella <SVELLA@novell.com>]

I have a hard time seeing any benefit in having multiple schemas. The primary drawback as I see it is that having to use an additional namespace in the "standard" bindings adds a small but annoying bit of complexity to both client and server implementations. It is possible to have two schema files but use a single namepace, but I don't really see the point of that either. 

Shon Vella
Software Engineer, Consultant
svella@novell.com
Novell, Inc., the leading provider of Net services software
www.novell.com 

>>> Jeff Parham <jeffparh@windows.microsoft.com> 09/25/01 05:59PM >>>
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