Action 05-09-19-02 Support for multiple inband XML schema

[Tommy Lindberg <tommy.lindberg@gmail.com>]

I had initially thought that the schema issue could be addressed by
simply changing the multiplicity of the <Schema> element wherever it
occurs - DocumentBaseType and SignatureObject.  Something like this
seemed like a possibility:

   <xs:element name="Schemas" type="dss:SchemasType"/>
   <xs:complexType name="SchemasType">
     <xs:sequence>
       <xs:element name="Schema" type="base64Binary" maxOccurs="unbounded"/>  
     </xs:sequence>
   </xs:complexType>

As Konrad pointed out during last weeks call, one disadvantage with this approach is that
it may potentially result in overhead; if multiple Document's use the same schema(s)
they would be carried multiple times - disregarding that the service may perform schema
caching. I note that this overhead is also currently present, possibly to a lesser extent
due to the singularity.

Konrad indicated that this could be mitigated if the schema was carried in an 
Optional Input - that is clearly more elegant and I concur with Konrad. 

The position of the single <Schema> element in the current DSS schema implies
(for both DocumentBaseType and SignatureObject) what document it relates/applies to. To achieve
the same effect for the multiplicity-adjusted <Schema> element, implemented as
an Optional Input, it becomes necessary to introduce additional attributes/elements.

As far as I can tell, the direction of the relationship could be either way; i.e. a Schema could
indicate what documents it pertains to OR a Document could indicate what schemas it depends
on (imports). Personally I prefer the latter.

Finally, processing MAY benefit from knowledge of the namespace without having to resort to
extracting it from the attached Schema(s).

An adjusted schema fragment (which would be the Optional Input) would look like this:

   <xs:element name="Schemas" type="dss:SchemasType"/>
   <xs:complexType name="SchemasType">
     <xs:sequence>
       <xs:element ref="dss:Schema" maxOccurs="unbounded"/>
     </xs:sequence>
   </xs:complexType>

   <xs:element name="Schema" type="dss:SchemaType"/> 
   <xs:complexType name="SchemaType">
     <xs:simpleContent>
       <extension base="base64Binary">
         <xs:attribute name="ID" type="xs:ID" use="required"/>
         <xs:attribute name="Namespace" type="xs:anyURI" use="optional"/>
       </xs:extension>
     </xs:simpleContent>
   </xs:complexType>


The required modification in DocumentBaseType and SignatureObject can be achieved in one of
two ways; through an IDREFS attribute or through a reference "container" element, each member
of which holding an IDREF attribute.

The following schema fragment illustrates the IDREFS approach:

  <xs:complexType name="DocumentBaseType" abstract="true">
    <!-- Old Schema element removed
    <xs:sequence>
      <xs:element name="Schema" type="xs:base64Binary" minOccurs="0"/>
    </xs:sequence>
    -->
    <xs:attribute name="ID" type="xs:ID" use="optional"/>
    <xs:attribute name="RefURI" type="xs:ID" use="optional"/>
    <xs:attribute name="RefType" type="xs:ID" use="optional"/>
    <xs:attribute name="SchemaRefs" type="xs:IDREFS" use="optional"/>
  </xs:complexType>

The following schema fragment illustrates the reference "container" element approach:

  <xs:complexType name="DocumentBaseType" abstract="true">
    <xs:sequence>
      <xs:element ref="SchemaRefs" minOccurs="0"/>
    </xs:sequence>
    <xs:attribute name="ID" type="xs:ID" use="optional"/>
    <xs:attribute name="RefURI" type="xs:ID" use="optional"/>
    <xs:attribute name="RefType" type="xs:ID" use="optional"/>
  </xs:complexType>

  <xs:element name="SchemaRefs" type="dss:SchemaRefsType"/>
  <xs:complexType name="SchemaRefsType">
    <xs:sequence>
      <xs:element ref="dss:SchemaRef" maxOccurs="unbounded"/>  
    </xs:sequence>
  </xs:complexType>

  <xs:element name="SchemaRef" type="dss:SchemaRefType"/>
  <xs:complexType name="SchemaRefType">
    <xs:attribute name="SchemaID" type="xs:IDREF" use="required"/> 
  </xs:complexType>


As the SignatureObject may occur in both a VerifyRequest and SignResponse, the <Schemas>
element should be both an Optional Input and Optional Output.

Regards,
Tommy