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: Anpassungen am VerificationReport-Schema

Hi all,

I came across some glitches in the core and profile schemas. In the core spec there is the element 'UseVerificationTime' defined but no type given. This would give an 'any' as the default type. Due to section '4.5.2 Optional Input <UseVerificationTime>' and as the schema suggests it should have the type 'UseVerificationTimeType':

   <xs:element name="UseVerificationTime" type="dss:UseVerificationTimeType"/>

    <xs:complexType name="UseVerificationTimeType">
            <xs:element name="CurrentTime" type="xs:dateTime"/>
            <xs:element name="SpecificTime" type="xs:dateTime"/>
            <xs:any namespace="##other"/>

The UseVerificationTimeType itself contains the "CurrentTime" element without a type, too. The core document doesn't explain it any further. In analogy to the 'SpecificTime' element the type 'xs:dateTime' should fit.


The XAdES schema uses two elements in an indicator style way (present or absent). That may cause problems with JAXB so I would propose to define a type of 'xs:boolean' for the use of JSON schema derivation:

SignaturePolicyImplied and AllSignedDataObjects

    <xsd:complexType name="SignaturePolicyIdentifierType">
            <xsd:element name="SignaturePolicyId" type="SignaturePolicyIdType" />
            <xsd:element name="SignaturePolicyImplied" type="xs:boolean"/>

    <xsd:complexType name="CommitmentTypeIndicationType">
            <xsd:element name="CommitmentTypeId" type="ObjectIdentifierType" />
                <xsd:element name="ObjectReference" type="xsd:anyURI" maxOccurs="unbounded" />
                <xsd:element name="AllSignedDataObjects" type="xs:boolean"/>
            <xsd:element name="CommitmentTypeQualifiers" type="CommitmentTypeQualifiersListType" minOccurs="0" />

And the Verification profile defines an element 'Other' with cardinality of [0..1] like the other siblings, but these elements do define list-type structures. So it would make sense to define a list-type element 'dss:AnyTypes' or to change the cardinality of 'Other to 'unbound'? In other occasions the Verification profiles explicitly defines unbound uses of 'dss:AnyType' I would propose it here, too:

  <complexType name="UnsignedPropertiesType">
            <element name="UnsignedSignatureProperties" type="vr:UnsignedSignaturePropertiesType" minOccurs="0" />
            <element ref="XAdES:UnsignedDataObjectProperties" maxOccurs="1" minOccurs="0" />
            <element name="Other" type="dss:AnyType" maxOccurs="unbounded" minOccurs="0"/>

    <complexType name="CertificateValuesType">
        <choice minOccurs="0" maxOccurs="unbounded">
            <element name="EncapsulatedX509Certificate" type="vr:CertificateValidityType" />
            <element name="OtherCertificate" type="xades:AnyType"/>

Andreas Kühne 
phone: +49 177 293 24 97 
mailto: kuehne@trustable.de

Trustable Ltd. Niederlassung Deutschland Gartenheimstr. 39C - 30659 Hannover Amtsgericht Hannover HRB 212612

Director Andreas Kühne

Company UK Company No: 5218868 Registered in England and Wales 

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