[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dss] RE: Emailing: EPMService-schema-verify.xsd
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]