OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dss message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]