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

 


Help: OASIS Mailing Lists Help | MarkMail Help

dss message

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


Subject: Re: [dss] Proposal for verification time and signing time issuesfound in DSS Core


Hi, just two comments intermixed:

>  
> 
> <AdditionalTimeInfo> [Optional]
> 
>       Any other time instant(s) relevant in the context of the 
> verification time determination.
> 
>  
>  
> 
>       <xs:element name="VerificationTimeInfo" 
> type="VerificationTimeInfoType"/>
> 
>       <xs:complexType name="VerificationTimeInfoType">
> 
>             <xs:sequence>
> 
>                   <xs:element name="VerificationTime" type="xs:dateTime"/>
> 
>                   <xs:element name="AdditionalTimeInfo" minOccurs="0" 
> maxOccurs="unbounded">
> 
>                         <xs:complexType>
> 
>                              <xs:complexContent>
> 
>                                     <xs:extension base="dss:AnyType">
> 
>                                          <xs:attribute name="Type" 
> type="xs:anyURI" use="required"/>
> 
>                                          <xs:attribute name="Ref" 
> type="xs:string" use="optional"/>                                    
> 
>                                    </xs:extension>
> 
>                              </xs:complexContent>
> 
>                         </xs:complexType>
> 
>                   </xs:element>
> 
>             </xs:sequence>
> 
>       </xs:complexType>
> 
>  
<jc>
1. The text says that AdditionaTimeInfo contains relevant time 
instant(s)... I would say that the schema for AdditionalTimeInfo should 
read:

<xs:extension base="dss:dateTime"> instead <xs:extension base="dss:AnyType">

2. I would put the declaration of AdditionalTimeInfo as a direct child 
of the root element of the schema, and use a reference to that element 
in the definition of <VerificationTimeInfo>. This would allow to make 
reference to this element from other places if required. This is more or 
less the strategy used for the rest of elements in the core schema. This 
means that the schema could be something like:

        <xs:element name="AdditionalTimeInfo">
            <xs:complexType>
                <xs:complexContent>
                    <xs:extension base="dss:dateTime">
                        <xs:attribute name="Type" type="xs:anyURI" 
use="required"/>
                            <xs:attribute name="Ref" type="xs:string" 
use="optional"/>
                    </xs:extension>
               </xs:complexContent>
          </xs:complexType>
       </xs:element>

       <xs:element name="VerificationTimeInfo" 
type="VerificationTimeInfoType"/>
       <xs:complexType name="VerificationTimeInfoType">
             <xs:sequence>
                   <xs:element name="VerificationTime" type="xs:dateTime"/>
                   <xs:element ref="dss:AdditionalTimeInfo" 
minOccurs="0" maxOccurs="unbounded"/>
             </xs:sequence>
       </xs:complexType>


</jc>
> 


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