Core versus Extended Profile Handling

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

As per minutes of Nov 3rd, here are the questions to kick off the thread on
core versus extended profile handling.

Question 1
**********

There are 3 (perhaps more) general approaches to handling extensibility on
the core. They are roughly described as follows.

A) Extension on Base Approach

    - The core would define dss: specific complexTypes and the profile would
specify an xs:extension base= construct to extend the core type
    - This would apply equally to Options structures, request structures,
and Output structures, perhaps even results structures
    - New complexTypes could be introduced when no base exists to extend 

Example:

<!-- This would be in the core for example -->

   <xs:complexType name="OptionsType">
     <xs:sequence>
       <xs:element name="IncludeContentTimeStamp" type="xs:boolean"
minOccurs="0"/>
       <xs:element name="IncludeSignatureTimeStamp" type="xs:boolean"
minOccurs="0"/>
     <xs:sequence
   </xs:complexType>


   <!-- This is a draft sample of a profile extension
   which inherits then extends the base -->

   <xs:complexType name="ABCOptionsType">
     <xs:complexContent>
       <xs:extension base=dss:OptionsType>
         <xs:sequence>
           <!-- TimeStamping Options -->
           <xs:element name="IncludeTimeStampXAdES-X" type="xs:boolean"
minOccurs="0"/>
                ...             ...
           <!-- Return Additional Info Options -->
           <xs:element name="ReturnExtendedStatusInfo" type="xs:boolean"
minOccurs="0"/>
             ...
         <xs:sequence>
       <xs:extension>
     <xs:complexContent>
   </xs:complexType>  



B) unbounded Choice with catch-all <any .../> as in XMLDSIG (see KeyInfoType
example below)

   <element name="KeyInfo" type="ds:KeyInfoType"/> 
   <complexType name="KeyInfoType" mixed="true">
     <choice maxOccurs="unbounded">     
       <element ref="ds:KeyName"/> 
       <element ref="ds:KeyValue"/> 
       <element ref="ds:RetrievalMethod"/> 
       <element ref="ds:X509Data"/> 
       <element ref="ds:PGPData"/> 
       <element ref="ds:SPKIData"/>
       <element ref="ds:MgmtData"/>
       <any processContents="lax" namespace="##other"/>
       <!-- (1,1) elements from (0,unbounded) namespaces -->
     </choice>
     <attribute name="Id" type="ID" use="optional"/> 
   </complexType>

C) totally separate schemas which import and ref from the base dss schema

    - implementations would be expected to reuse wherever possible but would
be free to redefine complex elements
    - could be used in conjunction with A) and B) above
    - essentially a loose-conformance approach


Is there a preferred technique ? Please express your preference and/or
suggest alternatives ?


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


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