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

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

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

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

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

<ed>Are you suggesting 2 schema ? One were DSS owns and hosts, and this just
carries Sign,Verify, and the other where EPM owns, which is what I sent
?</ed>

</ed>I was hoping to keep it under a single package for EPM customers using
a DSS compliant subset when utilizing Sign and Verify ? No ?</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 point, I guess you are saying DSS should own Sign and
Verify, EPM would own the rest. But EPM could reuse common types as it does
for Verify as attached. Yes ?

Does that make sense?

<ed> I think so. I'll reverse the order for DSS operations.</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. 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


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 


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
.