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

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

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. There are other examples.

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

That would cover all the really important and major constructs i.e. outputs,
options, and inputs. I know ... technically Options is part of the request,
that is your position, I see that. It is just that these additional elements
aren't options, they aren't even side-effects or co-requisites of Options,
but just sundry input.

What do you think ?

Ed

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

At 04:35 PM 11/8/2003 -0500, Edward Shallow wrote:

>Ignore last message, I didn't finish it. Here goes again ...
>
> >- I couldn't reference DSS at the VerifyRequest level because I need 
> >to define my own Options (which is a child) as we discussed. Ref'ed 
> >DSS wherever possible.
>
>The result of this is that an EPM protocol message isn't a DSS protocol 
>message.  Instead, I think we'd like EPM/DSS messages to look like:
>
><dss:VerifyRequest>
>    <dss:Options>
>      <dss:ServiceProfile>http://www.upu.org/epm</ServiceProfile>
>      <epm:TransactionKey>...</TransactionKey>
>      <epm:OrganizationID>...</OrganizationID>
>      .
>      .
>    </dss:Options>
>    <dss:Signature>...</dss:Signature>
>    <dss:InputDocuments>...</dss:InputDocuments>
></dss:VerifyRequest>
>
>Note that everything is in the DSS namespace except the Options / 
>Outputs specific to EPM.  So I'm thinking EPM would have a schema that 
>defines its Options and Outputs.
>
><ed>I don't mind. Are you saying that the DSS schema should be the 
>hosting schema, and that the EPM schema should be imported ?

Yeah, that's what I'm thinking - if you want a single schema for EPM's
Sign/Verify messages, it would be a copy of the DSS schema, with the EPM
extensions schema imported, and then with <dss:Options> and <dss:Outputs>
redefined to be more specific.  The targetNamespace for this schema would be
the DSS namespace.

So this means that EPM's Sign/Verify messages would need 2 schemas:
  1) one to contain the new Options and Outputs EPM defines
  2) the other to mix these Options and Outputs into the DSS core

This 2nd schema is only necessary for "machine consumption" - i.e. 
code-generation or validation.  For human consumption, just a little bit of
normative text could describe things in a more concise form ("The EPM
profile consists of DSS with the following options supported: 
<dss:KeySelector>, <epm:AccountID>, ...").


>  The only reason I did
>it this way, is that I have a slew of other operations (12 in all) each 
>with their own request, response, and options structures. I was 
>thinking that the EPM is the superset, and when one is using the DSS 
>subset, they are compliant.

But with the schema you sent, EPM *wouldn't* be compliant with the DSS
subset, in this sense: if a client who doesn't know about the EPM superset
sends a <dss:VerifyRequest> to an EPM server, the server would be expecting
an <epm:VerifyRequest> instead and would give an error.


>  They are however still running within the EPM profile. I can flip it 
>I guess, since it would be only for the Sign and Verify, right ?</ed>

Sure, I don't think we care about anything else.



>Then you could just use normative text to say which options from the 
>core are also allowed.  Then, if you want a schema that fully describes 
>EPM/DSS messages, for code-generation or real-time-validation, then you 
>would create another schema that would be a modified copy of the DSS 
>core schema, but with <Options> and Outputs defined as an <xs:all> of 
>the allowed DSS and EPM Options and Ouptuts.
>
><ed> On this last 2 points, I guess you are saying DSS should own Sign 
>and Verify, EPM would own the rest. But EPM could reuse common types 
>across all its verbs as it does for the attached. Yes ?

I'm not sure.  I explain this in more detail in my first comment in this
mail.  I can't tell if what you're describing is the same.  If it's still
unclear let me know.


> >- Outputs and Options seem to fit fine, not sure if I like 
> >VerifyRequest due to missing extensibility point
>
>What's wrong with <Options> as the extensibility point?  Couldn't your 
><OrganizationID>, <AccountID>, etc., all go under <Options>?
>
><ed>I thought Options were processing directives ? These elements and 
>others like it (e.g. TransactionKey) are really sundry but 
>pre-requisite input request elements. Grammatically and conceptually 
>they are not really Options. It would be messy (given the EPM schemas 
>present uniformity to throw request elements into the Options structure 
>for but 2 of the 12 operations. Not impossible, not invalid, but 
>terribly messy and inconsistent from an EPM user's viewpoint. Can you 
>suggest other approaches, that leave Options as simply Processing 
>Directives that can be expressed as simple booleans or empty named tags 
>?</ed>

I was thinking we would toss *everything* except the irreducibly core stuff
into <Options> and <Outputs>.  That way, a DSS profile could be fully
described by saying what options/outputs it supports.  Already, we're
putting things like <KeySelector> into options, which is not just a simple
boolean or empty named tag.

This way, all extension of DSS are confined under a single element, and
should play by the same rules:
  - ordering of options and outputs shouldn't matter
  - options can be omitted
  - servers can return outputs the client didn't explicitly request

That uniformity should make it easier for programmers to support different
profiles, and for standards developers to describe profiles, and borrow
elements from each other.

I can believe this makes DSS messages look inconsistent with other EPM
messages, but this kind of trade-off might be unavoidable with standards: 
if EPM plays by the DSS rules, then it has to put up with structures that
are less tailored and optimized to it, but it gains the advantage of
interoperability with DSS software, so hopefully the balance is positive...

So I dunno, let me know how you feel about turning everything into
Options/Outputs, and how big an issue this is.


Couple other comments:

>Your Options are all booleans.  The DSS core has the <ContentTimestamp> and
><SignatureTimestamp> options, which are booleans that default to false when
>absent.  The nice thing about keeping Options "optional" like this is that
>clients that don't know about these options can still get service from any
>DSS server.  This sort of interoperability is *very* desirable, so I
>encourage you to support this.
>
><ed>I hear you. Our booleans can be nilled, or left out altogether. They
>also default to false. This is more of a backward compatibility issue.

By backwards-compatibility do you mean compatible with older versions of 
EPM, or with DSS?


>  But
>we are not going to get away without some change in the DSS-rev of the EPM
>schema, so I guess everything is up for grabs as we move forward.</ed>
>
>Also, for your Options and Outputs, I think they should be an <xs:all>
>instead of a sequence, so they could be sent in any order.
>
><ed>No problem</ed>

cool.


Trevor 


To unsubscribe from this mailing list (and be removed from the roster of the
OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/dss/members/leave_workgroup.php
.