RE: Emailing: EPMService-schema-verify.xsd

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

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

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 ?

Does that make sense?

<ed> I think so. I'll reverse the order for DSS operations. Is that it
?</ed>



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

<ed>Under that definition, yes. Consider it done</ed>



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


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


Trevor