OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dss-x message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: [OASIS Issue Tracker] (DSSX-31) Public Comment 201809c00001s07


     [ https://issues.oasis-open.org/browse/DSSX-31?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andreas Kuehne updated DSSX-31:
-------------------------------
    Assignee: Andreas Kuehne

> Public Comment 201809c00001s07
> ------------------------------
>
>                 Key: DSSX-31
>                 URL: https://issues.oasis-open.org/browse/DSSX-31
>             Project: OASIS Digital Signature Services eXtended (DSS-X) TC
>          Issue Type: Bug
>    Affects Versions: PRD01
>            Reporter: Andreas Kuehne
>            Assignee: Andreas Kuehne
>            Priority: Major
>              Labels: PRD01_COMMENT, TC_ESI
>
> 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|http://lists.oasis-open.org/archives/dss-x-comment/201809/msg00001.html]Âper attachment with accessibility issues (word file)
> {quote}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
> {quote}
> h2. 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.|



--
This message was sent by Atlassian JIRA
(v7.7.2#77003)


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]