[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: Emailing: EPMService-schema-verify.xsd
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]