RE: XKMS Schema issue 22

A tweak here, the schea as specified requires a tweak to prevent a compound
request containing nested compound requests. I do not think that is a route
we want to take. A minor correction to the schema avoids this problem.
 
We could even segregate so that a compound request could consist of a
mixture of X-KISS request types or X-KRSS request types but not both.
 
Also missing is the compound response!!!

-----Original Message-----
From: Hallam-Baker, Phillip [mailto:pbaker@verisign.com]
Sent: Wednesday, September 25, 2002 4:52 PM
To: XKMS
Subject: XKMS Schema issue 22


 
 
Issue 22 Bulk Requests
 
There is an issue of schema design here, how to express a multiple request?
 
Question: Do we want to be able to issue different request types at the same
time?
 
E.G. 3 <Locate> and 4 <Validate> ???
 
This may make some sense when it comes to bulk registration issues, it would
allow you to request a recovery and revocation in the same step (quite
likely if you have just fired Mallet).
 
The answer to this question affects the schema design
 
 
Option 1:
 
<!-- CompoundRequest -->
<element name="RequestAbstract" type="xkms:RequestAbstractType"/>
<element name="CompoundRequest" type="xkms:CompoundRequestType"/>
    <complexType name="CompoundRequestType">
        <complexContent>
            <extension base="xkms:RequestAbstractType">
                <sequence>
                    <element ref="xkms:RequestAbstract" minOccurs="0"
maxOccurs="unbounded"/>
                <sequence>
            </extension>
        </complexContent>
</complexType>
<!-- /CompoundRequest -->
 
And we specify that each of the requests is a member of the Abstract Request
substitution group
 
Pro:        This works really well for extensibility
Con:        We cannot restrict the multiple request to be n requests of the
same type
Con:        Requires support for substitution groups (is this a problem
framework folks)?
 
Option 2:
 
We enumerate the defined request types
 
Pro:        Simple to implement
Con:        Does not extend very well
<element name="CompoundRequest" type="xkms:CompoundRequestType"/>
<complexType name="CompoundRequestType">
    <complexContent>
        <extension base="xkms:RequestAbstractType">
            <choice minOccurs="1" maxOccurs="unbounded">
                <element ref="xkms:LocateRequest"/>
                <element ref="xkms:ValidateRequest"/>
                <element ref="xkms:RegisterRequest"/>
                <element ref="xkms:ReissueRequest"/>
                <element ref="xkms:RecoverRequest"/>
                <element ref="xkms:RevokeRequest"/>
            </choice>
        </extension>
    </complexContent>
</complexType>


 
Option 3:
 
We enumerate the defined requests with a constraint that the requests be all
of the same type:
 
Pro:        Simple to implement
Con:        Does not extend well
<element name="CompoundRequest" type="xkms:CompoundRequestType"/>
<complexType name="CompoundRequestType">
    <complexContent>
        <extension base="xkms:RequestAbstractType">
            <choice>
                <element ref="xkms:LocateRequest" minOccurs="1"
maxOccurs="unbounded"/>
                <element ref="xkms:ValidateRequest" minOccurs="1"
maxOccurs="unbounded"/>
                <element ref="xkms:RegisterRequest" minOccurs="1"
maxOccurs="unbounded"/>
                <element ref="xkms:ReissueRequest" minOccurs="1"
maxOccurs="unbounded"/>
                <element ref="xkms:RecoverRequest" minOccurs="1"
maxOccurs="unbounded"/>
                <element ref="xkms:RevokeRequest" minOccurs="1"
maxOccurs="unbounded"/> 
            </choice>
        </extension>
     </complexContent>
</complexType>

My preferred option is #1 but I have implemented #2 at present since #1
would be harder to back out completely.