At 05:26 PM 11/5/2003 -0500, Edward Shallow wrote:
>As per minutes of Nov 3rd, here are the questions to kick off the thread on
>core versus extended profile handling.
my votes -
>Question 1
>**********
>
>There are 3 (perhaps more) general approaches to handling extensibility on
>the core. They are roughly described as follows.
I'm happy with having <Options> be a sequence of <xs:any>, and then using
normative text in profiles to say which options are allowed.
But we could also do stricter schema-typing, if people want.
>Question 2
>**********
>
>As it pertains to core versus extended, should the core endevor to define
>optional elements that can or might be (re)used by extended profiles, or
>should this element definition be left to the profile implementor ? If yes,
>should the core also define any optional elements that would also be
>required (e.g. additional outputs).
yes - the core should define common options/outputs that multiple profiles
might find useful (like the current <KeySelector>, <IntendedAudience>,
<ClaimedIdentity>, <SignatureTimestamp>/<ContentTimestamp>, etc..).
>Question 3
>**********
>
>Should DSS implementors be obliged to support all core operations and
>options designated as mandatory, or should DSS conformance be more loosely
>defined, if at all ? Should there be any "branding" or PlugTests to receive
>such an "OASIS DSS-compliant" branding or "seal of conformance" ?
I think every DSS server should accept <InputDocument>s and return a
<Signature> for signing, similarly accept a <Signature> and return a
<Result> for verifying. Aside from that basic functionality, it should be
left up to profiles to determine which <Options>/<Outputs> are supported.
So as far as a "seal of conformance" goes, I think that would be for
conformance to a profile, not to DSS itself. However, profiles would have
a lot of commonality, hopefully - so that a client implementation of the
DSS core should be easy to make conformant with a lot of different profiles.
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.
