Uploaded image for project: 'OASIS Digital Signature Services eXtended (DSS-X) TC'
  1. OASIS Digital Signature Services eXtended (DSS-X) TC
  2. DSSX-31

Public Comment 201809c00001s07: restricted cardinality

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: PRD01
    • Fix Version/s: None
    • Component/s: None
    • Resolution:
      Hide

      Fix XML schema, align test cases, check generated documentation and JSON scheme

      Show
      Fix XML schema, align test cases, check generated documentation and JSON scheme

      Description

      Comments from TC ESI to OASIS DSS-X TC on DSS-X V2 -  7 of 19 submitted by Liaison Andreas Kuehne on behalf of Sonia Companies via message  201809c00001 per attachment with accessibility issues (word file)

      following steering committee call on 17/09 and addition of 2 other editorial comments, the resulting pre-agreed comments are now for ESI approval for submission to OASIS DSS-X TC by 28 September

      Comment  #7:

      Clause 4.3.4.2. XML Schema for OptionalInputsSignType.
       
      The definition of SignRequest includes the following sub-component:
      <xs:element minOccurs="0" name="OptionalInputs"
                          type="dss2:OptionalInputsSignType"/>

      And then the definition of OptionalInputsSignType is as follows:
      <xs:complexType name="OptionalInputsSignType">
        <xs:complexContent>
          <xs:extension base="dss2:OptionalInputsBaseType">
            <xs:sequence>
              <xs:choice>
                <xs:element maxOccurs="1" minOccurs="0" name="SignatureType"
                            type="xs:anyURI"/>
                <xs:element maxOccurs="1" minOccurs="0" name="IntendedAudience"
                            type="dss2:IntendedAudienceType"/>
                <xs:element maxOccurs="unbounded" minOccurs="0" name="KeySelector"
                            type="dss2:KeySelectorType"/>
                <xs:element maxOccurs="1" minOccurs="0" name="Properties"
                            type="dss2:PropertiesHolderType"/>
                <xs:element maxOccurs="unbounded" minOccurs="0" name="IncludeObject"
                            type="dss2:IncludeObjectType"/>
                <xs:element default="false" maxOccurs="1" minOccurs="0"
                            name="IncludeEContent" type="xs:boolean"/>
                <xs:element maxOccurs="1" minOccurs="0" name="SignaturePlacement"
                            type="dss2:SignaturePlacementType"/>
                <xs:element maxOccurs="1" minOccurs="0" name="SignedReferences"
                            type="dss2:SignedReferencesType"/>
                <xs:element maxOccurs="1" minOccurs="0" name="Nonce"
                            type="xs:integer"/>
                <xs:element maxOccurs="1" minOccurs="0" name="SignatureAlgorithm"
                            type="xs:string"/>
                <xs:element maxOccurs="1" minOccurs="0" name="SignatureQualityLevel"
                            type="xs:anyURI"/>
              </xs:choice>
            </xs:sequence>
          </xs:extension>
        </xs:complexContent>
      </xs:complexType>
       
      With these definitions one SignRequest CAN HAVE ONLYONE OPTIONAL INPUT (PLEASE NOTE THAT IN THE DEFINITION OF OptionalInputsBaseType THE SEQUENCE ONLY HAS ONE ELEMENT: A CHOICE BETWEEN A NUMBER OF OPTIONS, BUT ONLY ONE. Note also the absence of maxOccurs in the first schema piece for the element OptionalInputs.
       
      REQUEST: EITHER SUPPRESS THE CHOICE WITHIN THE SEQUENCE OR ADD A MAXOCCURS TO THE SEQUENCE. THE FIRST OPTION WOULD RESTRICT THE ORDER OF APPEARANCE OF THE OPTIONALINPUTS IN THE REQUEST. THE SECOND WOULD ALLOW ANY ORDER.|

      AK: the problem is not to require strict order that the JSON syntax can not impose.
      JC: OK, but then if there are restrictions to the number of sub-components that are not captured by the Schemas, there must be text requirements imposing them.

        Attachments

          Activity

            People

            • Assignee:
              kuehne Andreas Kuehne
              Reporter:
              kuehne Andreas Kuehne
            • Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: