Proposal: Use of XAdES EN in the revision of OPC

[MURATA Makoto]

> - However, JNSA would like to make sure that the
  DataObjectFormat element added in XAdES EN is optional.

Here is the definition of the complex type for the DataObjectFormat
element. I think that we should prohibit the use of the attribute MimeType
since OPC already specifies media types of parts.

<xsd:complexType name="DataObjectFormatType">
  <xsd:sequence>
   <xsd:element name="Description" type="xsd:string" minOccurs="0"/>
   <xsd:element name="ObjectIdentifier" type="ObjectIdentifierType"
        minOccurs="0"/>
   <xsd:element name="MimeType" type="xsd:string" minOccurs="0"/>
  <xsd:element name="Encoding" type="xsd:anyURI" minOccurs="0"/>
  </xsd:sequence>
  <xsd:attribute name="ObjectReference" type="xsd:anyURI"
     use="required"/>
</xsd:complexType>

Regards,
Makoto

2017-10-25 22:38 GMT+09:00 MURATA Makoto <eb2m-mrt at asahi-net.or.jp>:

> Dear colleagues,
>
> The Japanese mirror for SC34 discussed the use of XAdES in the
> revision of OPC.
>
> Miyachi-san of JNSA gave the following report:
>
> - JNSA agrees that XAdES EN be used in  the revision of the
>    ISO profile of XAdES
>
> - However, JNSA would like to make sure that the
>   DataObjectFormat element added in XAdES EN is optional.
>
> The Japanese mirror for SC34 believes that DataObjectFormat
> elements are not useful in the context of OPC.  This is
> because OPC already provides a mechanism for specifying
> media types of OPC parts.  DataObjectFormat elements
> provide another mechanism for specifying media types.
>
> Thus, Japan proposes that the revision of OPC should use XAdES EN
> without DataObjectFormat elements.
>
> Regards,
> Makoto
>



-- 

Praying for the victims of the Japan Tohoku earthquake

Makoto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.vse.cz/pipermail/sc34wg4/attachments/20171110/2fd6f189/attachment.html>