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

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

I like Inputs. However I think "AdditionalInputs" is even more accurate
given the assertion that ideally you don't have to specify anything and
still get served ... Hence anything above and beyond implicit is really
"Additional".

That is my vote, and thank you for the compromise. I can work within these
constraints.

Ed

   

-----Original Message-----
From: Trevor Perrin [mailto:trevp@trevp.net] 
Sent: November 9, 2003 1:20 PM
To: Edward Shallow; dss@lists.oasis-open.org
Subject: RE: [dss] RE: Emailing: EPMService-schema-verify.xsd

At 09:55 PM 11/8/2003 -0500, Edward Shallow wrote:

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

Rich says the same (and I agree too): this should be a SHOULD, not a MUST.


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

Yeah, the current drafts put everything except the most basic core stuff in
Options/Outputs.  Rich suggests we could change the name, but we probably
don't need 2 elements (one for Options, one for mandatory Inputs), and I
agree with that.

So we could rename <Options>, some choices:
   <Parameters> (Rich's initial choice)
   <Inputs> (would match "Outputs")
   <AdditionalInputs>
   <Specifiers>

Would this improve things, or would you still want to separate the optional
inputs from the mandatory ones?

If one of these names grabs you (or anyone else), let us know.


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

Yeah, everything above and beyond the <InputDocuments> and <Signature> and
<Result> are being stuffed in there.


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.

Sure.  That may be unavoidably mandatory, given your use case.  Perhaps you 
could use <ClaimedIdentity> for it, though - right now <ClaimedIdentity> is 
just a string, but we should change it to have a Format attribute that 
identifies the type of string (URL, emailAddress, DN, etc..).

A generic DSS toolkit might have support for <ClaimedIdentity> but not know 
about AccountID / OrgID, so this might make interop a little easier.


Trevor