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
