Re: Emailing: EPMService-schema-verify.xsd

[Trevor Perrin <trevp@trevp.net>]

At 01:30 PM 11/8/2003 -0500, Edward Shallow wrote:

>Trevor,
>
>     Here is a trial EPM schema (simplified partial) which references and
>extends the DSS Verify schema.

Thanks, this is a huge aid to the discussion.


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

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.

Does that make sense?



>- It would be helpful if RequestID were of type any, so I could use our
>TransactionKeyType

I thought the TransactionKey, in EPM, was for linking different protocol 
runs as part of the same transaction.  Whereas the RequestID is just to 
link responses with requests.  This seems like a different use, so I think 
<TransactionKey> should be done as a separate <Option>?



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


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.

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.


Trevor