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

["Edward Shallow" <ed.shallow@rogers.com>]

Do they have to always be there?  
<ed>TransactionKey does not always have to be there. As you might remember,
it is for the subset of transactions requiring "lifecycle" support</ed>
<ed>Org and Account as the names imply relate to billing, chargeback, and in
some cases (Encrypt) help us decide which keys to use,/ed> 

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."
<ed>I think that makes sense. But I can't concede that everthing falls into
that category.</ed>

<ed>Another example we have of an always present input element is
"ClientApplication". This is used for identifying the source of the call
when special provisions have been made for specific desktop tools like
Acrobat's Signing Framework, and Microsoft's InfoPath, which have their own
peculiarities. Although I can see this one defaulting if not present. I can
live with moving that as well.</ed>

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?

<ed>Are you saying that even if they can be defaulted in "some" cases, they
belong in Options ? When we first brought up Options, it was called
"ProcessingOptions" and served soley to direct server processing. It then
got generalized to also hold request structures which stood on their own
independent of Processing Directives. Now it is being asked to take in and
accommodate everything on the request side that isn't implicit.</ed>  

Could the TransactionKey default to none?
<ed>Yes, if one does not require lifecycle support (i.e. this is a lone
event). I don't have a problem moving TransactionKey into Options. Sold.
</ed>


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

<ed>Yes I see the virtue in this. I guess my biggest problem is in the
billing and chargeback. Telling customers which account we are going to
debit seems a little presumptuous. You know what a dog's breakfast internal
cost centres are in a big organization.
</ed>


Trevor