RE: [dss] RE: Emailing: EPMService-schema-verify.xsd

[Trevor Perrin <trevp@trevp.net>]

At 06:58 PM 11/8/2003 -0500, Edward Shallow wrote:

>Yeah I know what you are saying. An you are right that most of the time the
>additional input element is usually a consequence of an Options selction.
>But profiles will have input elements that are always there, regardless of
>operation and option. Our TransactionKey, OrganizationID, and AccountID are
>in this category.

Do they have to always be there?  I'm just thinking: whether these are 
<Options> or <AdditionalInputs> or something else, if an EPM server 
*requires* certain inputs from clients, then an EPM server won't be able to 
offer *any* service to clients that aren't explicitly tailored to it.

Right now the draft says: "All options must have some default value, so 
that a client may omit the <Options> element yet still get service from any 
DSS server."

Maybe that's too optimistic - but if you (and other profile designers) can 
find a way to make all extensions optional, that's a huge boon for DSS 
interoperability (for example: could OrganizationID and AccountID be 
derived from how the user authenticates, in some cases?  Could the 
TransactionKey default to none?)


>Do you think that it would be worth considering an "AdditonalInputs" element
>as an extensibility point to complete the picture ?

It depends on the previous issue, I think.  My first choice is do all 
extensions as <Options>, and have them all (or at least mostly) be optional.

But if you want to have extensions which are mandatory for the client to 
send, then calling them <Options> doesn't make as much sense.  So we could 
consider an <AdditionalInputs>, or renaming <Options>.

I'd just like to consider the previous issue some more.  I know making 
everything an Option limits what you can do as a profile designer - but if 
you can meet that constraint, the jobs of people using our stuff becomes 
much easier, cause they can count on a minimum of compatibility.


Trevor