How To Write A Technical Interoperability Standard For Spain
|
|
|
- Thomasina Cobb
- 5 years ago
- Views:
Transcription
1 TECHNICAL INTEROPERABILITY STANDARD For E-Files. GOBIERNO DE ESPAÑA MINISTERIO DE HACIENDA Y ADMINISTRACIONES PÚBLICAS SECRETARÍA DE ESTADO DE ADMINISTRACIONES PÚBLICAS DIRECCIÓN GENERAL DE MODERNIZACIÓN ADMINISTRATIVA, PROCEDIMIENTOS E IMPULSO DE LA ADMINISTRACIÓN ELECTRÓNICA
2 TÍTULO/TÍTLE: Technical Interoperability Standard for E-Files. Elaboración y coordinación de contenidos/content elaboration and coordination: Dirección General de Modernización Administrativa, Procedimientos e Impulso de la Administración Electrónica/ General Directorate for Administrative Modernization, Procedures and Promotion of Electronic Administration Características/Characteristics: Adobe Acrobat 5.0 Responsable edición digital: Subdirección General de Información, Documentación y Publicaciones/ Responsible for digital edition: Deputy directore for Information, Documentation and Publications (Jesús González Barroso) Así mismo, se puede encontrar esta publicación en el Portal de Administración Electrónica (PAe):/ Publication available at: Para ver estas Guías de aplicación... publicadas en 2011 ver :/ Technical Interoperability Standars 2011 available at: Edita: Ministerio de Hacienda y Administraciones Públicas Secretaría General Técnica Subdirección General de Información, Documentación y Publicaciones Centro de Publicaciones Edit: Ministry of Finance and Public Administration Technical Secretariat, Directorate General for Information, Documentation and Publications Publication Center NIPO:
3 OFFICIAL STATE GAZETTE III. OTHER PROVISIONS MINISTRY OF TERRITORIAL POLICY AND PUBLIC ADMINISTRATION Resolution of the Secretary of State for Public Service, of 19 July 2011, giving approval to the Technical Interoperability Standard for E-Files. The National Interoperability Framework, established in Article 42, Section 1, of Law 11/2007, of 22 J une, on Citizens E-Access to Public Services, is aimed at creating the conditions necessary to guarantee an adequate level of technical, semantic and organisational interoperability of the systems and app lications used in the Public Administration, allowing the exercise of rights and the fulfilment of obligations through e- access to public services, while acting in the interest of effectiveness and efficiency. Royal Decree 4/2010, of 8 January, regulating the National Interoperability Framework for E-Government, establishes in Additional Provision 1 t he development of a series of Technical Interoperability Standards, which must be complied with in the Public Administration. The Technical Interoperability Standards describe specific aspects of a wide range of topics such as e-documents, digitisation, e-files, authentic copy and conversion, signature policy, standards, data brokerage, data models, e-document management, connection to the communication network of the Spanish Public Administration, and data models for the exchange of registry entries and declarations of conformity, all of which are necessary to guarantee the more practical and operational aspects of interoperability between Public Administration agencies and citizens. The Technical Interoperability Standards shall be further developed and improved over time, parallel to the progress of e-government services, their supporting infrastructure, and the evolution of technology, in order to meet the provision in Article 42.3 of Law 11/2007, of 22 June. Within the Technical Interoperability Standards, those related to e-documents, e-files, the digitisation of paper documents, authentic copy and conversion procedures, and e- document management policy are in accordance with the provisions in the aforementioned Royal Decree 4/2010, of 8 January, on the Interoperability, Retrieval and Preservation of E-Documents, in light of the need to guarantee these aspects for e- documents throughout their lifecycle. In particular, the Technical Interoperability Standard for E-Files describes the structure of e-files, including e-documents, e-indexes, e-signatures, and m inimum required metadata, and the specifications to send them and make them available. For e-file management and pr eservation issues, this Standard cross-refers to the Technical Interoperability Standard for E-Document Management Policy. Finally, the Annexes to this Resolution contain a detailed definition of the minimum required metadata and XML schemas for file exchange. In this regard, the e-file structure as defined in this Standard allows the use of e-signatures as envisaged in the Commission Decision 2011/130/EU, of 25 February, 2011, establishing minimum requirements for the cross-border processing of documents signed electronically by competent authorities under Directive 2006/123/EC of the European Parliament and of the Council on services in the internal market.
4 Drafted in collaboration with all the Public Administration agencies to which it applies, the present Technical Standard has received a favourable report from the Standing Committee of the High Council for E-Government, at the proposal of the E-Government Sector Committee. In accordance with the provisions in Section 2 of Additional Provision 1 of Royal Decree 4/2010, of 8 January, the Secretary of State decides: One To approve the Technical Interoperability Standard for E-Files whose text appears below. Two That the Technical Interoperability Standard for E-Files that is being approved by virtue of this document shall come into force on t he day following its publication in the Official State Gazette, irrespective of the clauses in Transitory Provision 1 of Royal Decree 4/2010, of 8 J anuary, regulating the National Interoperability Framework for E- Government. Madrid, 19 July, Secretary of State for Public Service María Consuelo Rumí Ibáñez. TECHNICAL INTEROPERABILITY STANDARD FOR E-FILES Contents I. Purpose I. Scope of application II. Components of e-files III. Metadata of e-files IV. Exchange of e-files Annex I. Minimum required metadata of e-files Annex II. XML schemas for e-file exchange I. Purpose The Technical Interoperability Standard for E-Files is intended to establish the structure and format of e-files, as well as the specifications of the services to send them and make them available. II. Scope of application II.1 This standard shall apply to e-files within the scope established in Article 3 of Royal Decree 4/2010, of 8 January, regulating the National Interoperability Framework for E-Government. II.2 The specifications set forth in this Standard can be applied to other sets of e- documents which, having been created under no regulated procedures, are the result of a series of coherent actions leading to a specific outcome. III.1 The components of e-files are: III. Components of e-files a) E-documents, which shall comply with the structure and format specifications in the Technical Interoperability Standard for E-Documents. E-documents can be pa rt of e-files as independent elements or in folders, the
5 latter being sets of e-documents created for functional purposes, or as part of another file, embedded in the former. b) E-indexes which, according to the provisions in Article 32.2 of Law 11/2007, of 22 June, shall guarantee the integrity of e-files and their retrieval whenever necessary. E-indexes shall contain the whole set of e-documents associated with a file at a given moment and, if necessary, their distribution in folders or files. c) E-index signature by the Public Administration, body or intervening agency, in accordance with regulations in force. d) Metadata. III.2 The addition of an e -file to a document management system shall comply with the provisions in the Technical Interoperability Standard for E-Documents and the Technical Interoperability Standard for E-Document Management Policy. IV.1 The minimum required metadata of e-files: a) Shall be those in Annex I. IV. Metadata of e-files b) Shall be associated during e-file creation for sending e-files and making them available. c) Shall not be altered at any stage of the administrative procedures, except for changes that need to be introduced to correct errors or omissions in the values originally assigned. IV.2 Complementary metadata can be added in response to special description needs. When necessary, complementary metadata shall be applied in compliance with the provisions in the Technical Interoperability Standard for E-Document Management Policy. V. Exchange of e-files V.1 The exchange of e-files for sending them or making them available shall consist in sending the structure described in Annex II first, without precluding others set out in the corresponding regulations. Once the structure has been sent, each of the e-documents in the e-file shall be sent in the established order and in compliance with the Technical Interoperability Standard for E-Documents. V.2 As an exception, other structures can be used to exchange e-files between Public Administration agencies if the parties have agreed on such structures beforehand. In any case, e-files that must be sent to third parties must be converted by the sender to the structure defined in Annex II. V.3 When the nature or the size of the evidence or documents in the e-file make it difficult to fit in the established structures, a document shall be added specifying which are such documents or evidence. They shall be kept in custody by the managing body and provided separately if required. V.4 The e-index of the files being exchanged shall at least contain: a) The date of index creation. b) For each e-document, the identifier, digital footprint, summary function used to create them in compliance with the provisions in the Technical Interoperability Standard
6 for Catalogue of Standards, and optionally the date when and the order in which they were added to the file. c) If relevant, the distribution of documents in folders and the hierarchy of nested files. V.5 For the exchange of e-files between Public Administration agencies in automated processes: a) The Public Administration communication network should preferably be used as the means of file transfer. b) If the e-file is part of a registry entry, it shall be treated as an attachment to the exchange data message, in compliance with the Technical Interoperability Standard for Data Models for the Exchange of Registry Entries. V.6 In case of e-document exchanges between Public Administration agencies involving the transfer of permanent document management responsibilities, the transferor shall check the document s authenticity and integrity at the moment when the exchange takes place.
7 ANNEXES ANNEX I Minimum required metadata of e-files Metadata Description/Terms of use Repeatability 1F 1 Type Value schema NTI version Standard identifier of the version of the Technical Interoperability Standard for E-Files (NTI) according to which the e-file is structured. 1 URI Identifier Standard identifier of the e-file. 1 Character string Body Standard identifier of the agency in charge of the procedure/ 1:N Character string ES_<BodyUU>_<AAAA>_EXP_<Specific_ID >2F 2 Example: ES_E _2010_EXP_ MPR A single alphanumeric code for each body/unit/office extracted from the Common Directory managed by the Ministry of Territorial Policy and Public Administration. UExampleU: E File opening date Date when the file is opened. 1 Date/time Format: AAAAMMDD T HH:MM:SS <ISO 8601> Classification Administrative procedure the file is associated with. 1 Character string Status File status at the moment of the exchange. 1 Character string Interested party Identifier of the interested party. 0:N Character string Standard value schema according to the System of Administrative Information (SIA). If the procedure cannot be found in SIA: <Body >_PRO_<Specific_ID_PRO >3F 3 - Open - Closed - Sending index closed a) If citizen or legal entity, ID/FIN/TIN or others. b) If Public Administration, <Body UU>. 1 In the table, repeatability refers only to the metadata accompanying a file in an exchange, irrespective of other metadata assigned and managed internally by each Public Administration agency in compliance with the Technical Interoperability Standard for E-document Management Policies. 2 E-document identifier encoding: <Body>: See encoding of Body metadata. If there is more than one body, the nine corresponding characters shall be agreed upon by the parties to ensure identifier uniqueness, which is their only purpose. <AAAA>: File creation year (4 characters). <Specific_ID>: Alphanumeric code uniquely identifying the document among those created by the relevant Public Administration agency. Each agency can design its own generation process according to its own needs as long as it ensures uniqueness. 3 Metadata encoding when the procedure is not found in SIA: <Body>: See encoding of Body metadata. <Specific_ID_PRO>: Alphanumeric code uniquely identifying the document among those created by the relevant Public Administration agency. Each agency can design its own generation process according to its own needs as long as it ensures uniqueness. Therefore, this ID can be generated in a sequence or be a replica of the ID used internally (30 characters).
8 Signature type Indication of the type of signature attached to the document. 1:N Character string For signature type = CSV CSV value Value of CSV. 1:N Character string - CSV. - E-signature formats for e-documents as defined in the Technical Interoperability Standard for Signature and Certification Policies in the Public Administration. N/A. CSV generation definition Reference to the decree, resolution, or document establishing the creation of the corresponding CSV. 1:N Character string For the General Administration (AGE): BOE (Official Spanish Gazette) reference: BOE-A-YYYY-XXXXX For others: corresponding reference.
9 ANNEX II XML schemas for e-file exchange 1. E-file XSD Legend: expediente: file indice: index metadosexp: FileMetadata VisualizaciónIndice: IndexView DatosXML: XMLData ValorBinario: BinaryValue referenciafichero: FileReference NombreFormato: FormatName <?xml version="1.0" encoding="utf -8"?> <xsd:schema xmlns:xsd=" xmlns:eniexpind=" xmlns:eniexpmeta=" xmlns:eniexp=" xmlns.enifile=
10 targetnamespace=" elementformdefault="qualified" attributeformdefault="unqualified"> <xsd:documentation xml:lang="es"> E-FILE XSD ENI (v1.0)</xsd:documentation> <xsd:import namespace=" schemalocation=" <xsd:import namespace=" schemalocation=" <xsd:import namespace=" schemalocation=" <xsd:element name="file" type="eniexp:filetype"/> <xsd:complextype name=" FileType"> <xsd:documentation>
11 For e-file exchange, first the file s index is sent. Then, the documents contained in the file, one by one, after the distribution in the index contents. </xsd:documentation> <xsd:sequence> <xsd:element ref="eniexpind:index"/> <xsd:element ref="eniexpmeta:metadataexp"/> <xsd:element name="indexview" type="enifile:contenttype" minoccurs="0" maxoccurs="1"/> </xsd:sequence> <xsd:attribute name="id" type="xsd:id" use="optional"/> </xsd:schema> 2. File e-index XSD Legend: Indice: index IndiceContenido: ContentIndex Firmas: signatures <?xml version="1.0" encoding="utf -8"?> <xsd:schema xmlns:xsd=" xmlns:enids=" xmlns:eniexpind=" xmlns:eniconexpind=" targetnamespace=" elementformdefault="qualified" attributeformdefault="unqualified"> <xsd:documentation xml:lang="es"> E-FILE INDEX XSD ENI (v1.0) </xsd:documentation> <xsd:import namespace=" schemalocation=" <xsd:import namespace=" schemalocation=" <xsd:element name="index" type="eniexpind:indextype"/> <xsd:complextype name="indextype"> <xsd:sequence> <xsd:element name="contentindex" type="eniconexpind:contentindextype"/> <xsd:element ref="enids:signatures">
12 <xsd:documentation>there must be at least one signature of the e-file index contents.</xsd:documentation> </xsd:element> </xsd:sequence> <xsd:attribute name="id" type="xsd:id" use="optional"/> </xsd:schema>
13 3. File e-index content XSD
14 Legend: IndiceContenido: ContentIndex FechaIndiceElectronico: E-IndexDate DocumentoIndizado: IndexedDocument IdentificadorDocumento: DocumentIdentifier ValorHuella: FootprintValue FuncionResumen: SummaryFunction FechaIncorporacionExpediente: FileAdditionDate OrdenDocumentoExpediente: FileDocumentOrder ExpedienteIndizado:IndexedFile FechaIndiceExpediente: E-IndexDate DocumentoIndizado: IndexedDocument ExpedienteIndizado: IndexedFile CarpetaIndizado: IndexedFolder CarpetaIndizada: IndexedFolder IdentificadorCarpeta: FolderIdentifier DocumetoIndizado: IndexedDocument ExpedienteIndizado: IndexedFile CarpetaIndizado: IndexedFolder <?xml version="1.0" encoding="utf -8"?> <xsd:schema xmlns:xsd=" xmlns:eniconexpind=" targetnamespace=" elementformdefault="qualified" attributeformdefault="unqualified"> <xsd:documentation xml:lang="es">e-file INDEX CONTENTS XSD ENI (v1.0) </xsd:documentation> <xsd:element name="contentindex" type="eniconexpind:contenindextype"/> <xsd:complextype name="contenindextype"> <xsd:sequence> <xsd:element name="e-indexdate" type="xsd:datetime"/> <xsd:choice maxoccurs="unbounded"> <xsd:element name="indexeddocument" type="eniconexpind:indexeddocumenttype"/> <xsd:element name="indexedfile" type="eniconexpind:contenindextype"/> <xsd:element name="indexedfolder" type="eniconexpind:indexedfoldertype"/> </xsd:choice> </xsd:sequence> <xsd:attribute name="id" type="xsd:id" use="optional"/> <xsd:complextype name="indexeddocumenttype"> <xsd:sequence> <xsd:element name="documentidentifier" type="xsd:string"/>
15 <xsd:element name="footprintvalue" type="xsd:string"/> <xsd:element name="summaryfunction" type="xsd:string"/> <xsd:element name="fileadditiondate" type="xsd:datetime" minoccurs="0"/> <xsd:element name="filedocumentorder" type="xsd:string" minoccurs="0"/> </xsd:sequence> <xsd:attribute name="id" type="xsd:id" use="optional"/> <xsd:complextype name="indexedfoldertype"> <xsd:sequence> <xsd:element name="folderidentifier" type="xsd:string"/> <xsd:choice maxoccurs="unbounded"> <xsd:element name="indexeddocument" type="eniconexpind:indexeddocumenttype"/> <xsd:element name="indexedfile" type="eniconexpind:contentindextype"/> <xsd:element name="indexedfolder" type="eniconexpind:indexedfoldertype"/> </xsd:choice> </xsd:sequence> <xsd:attribute name="id" type="xsd:id" use="optional"/> </xsd:schema>
16 4. E-file metadata XSD Legend: metadatosexp: FileMetadata VersionNTI: NTIVersion Identificador: Identifier Organo: Body FechaAperturaExpediente: FileOpeningDate Clasificacion: Classification Estado: Status Interesado: InterestedParty <?xml version="1.0" encoding="utf-8"?> <xsd:schema xmlns:xsd=" xmlns:eniexpmeta=" targetnamespace=" elementformdefault="qualified" attributeformdefault="unqualified"> <xsd:documentation xml:lang="es">e-file METADATA XSD ENI (v1.0) </xsd:documentation>
17 <xsd:element name="filemetadata" type="eniexpmeta:metadatatype"/> <xsd:complextype name="metadatatype"> <xsd:sequence> <xsd:element name="ntiversion" type="xsd:anyuri"/> <xsd:element name="identifier" type="xsd:string"/> <xsd:element name="body" type="xsd:string" minoccurs="1" maxoccurs="unbounded"/> <xsd:element name="fileopeningdate" type="xsd:datetime"/> <xsd:element name="classification" type="xsd:string"/> <xsd:element name="status">
18 <xsd:documentation xml:lang="es"> - E01 - Open. - E02 - Closed. - E03 - Sending index closed. </xsd:documentation> <xsd:complextype> <xsd:simplecontent> <xsd:extension base="eniexpmeta:statuslist"/> </xsd:simplecontent> </xsd:element> <xsd:element name="interestedparty" type="xsd:string" minoccurs="0" maxoccurs="unbounded"> <xsd:documentation xml:lang="es">required field when there is at least one interested party.</xsd:documentation> </xsd:element> </xsd:sequence> <xsd:attribute name="id" type="xsd:id" use="optional"/> <! File Status List --> <xsd:simpletype name="statuslist"> <xsd:restriction base="xsd:string"> <xsd:enumeration value="e01"/> <xsd:enumeration value="e02"/> <xsd:enumeration value="e03"/> </xsd:restriction> </xsd:simpletype> </xsd:schema>
19 5. Signature XSD Legend: firmas: signatures firma: signature TipoFirma: SignatureType ContenidoFirma: SignatureContent CSV: CSV ValorCSV: CSVValue RegulacionGeneracionCSV: CSVGenerationRegulation FirmaConCertificado: SignatureWithCertificate FirmaBase64: Base64Signature Firma: Signature ReferenciaFirma: SignatureReference <?xml version="1.0" encoding="utf-8"?> <xsd:schema xmlns:xsd=" xmlns:enids=" xmlns:ds=" targetnamespace=" " elementformdefault="qualified" attributeformdefault="unqualified"> <xsd:documentation xml:lang="es">e-signature XSD ENI (v1.0)</xsd:documentation> <xsd:import namespace=" schemalocation="
20 <xsd:element name="signatures" type="enids:signatures"/> <xsd:complextype name="signatures"> <xsd:sequence> <xsd:element name="s" type="enids:e-signaturetype" minoccurs="1" maxoccurs="unbounded"/> </xsd:sequence> <xsd:complextype name="e-signaturetype"> <xsd:sequence> <xsd:element name="signaturetype"> <xsd:documentation xml:lang="es"> - TF01 - CSV. - TF02 - XAdES internally detached signature. - TF03 - XAdES enveloped signature. - TF04 - CAdES detached/explicit signature. - TF05 - CAdES attached/implicit signature.
21 L. D.: M-1/ ISSN: X - TF06 - PAdES. </xsd:documentation> <xsd:simpletype> <xsd:restriction base="xsd:string"> <xsd:enumeration value="tf01"/> <xsd:enumeration value="tf02"/> <xsd:enumeration value="tf03"/> <xsd:enumeration value="tf04"/> <xsd:enumeration value="tf05"/> <xsd:enumeration value="tf06"/> </xsd:restriction> </xsd:simpletype> </xsd:element> <xsd:element name="signaturecontent"> <xsd:complextype> <xsd:choice> <xsd:element name="csv"> <xsd:complextype> <xsd:sequence> <xsd:element name="csvvalue" type="xsd:string"/> <xsd:element name="csvgenerationregulation" type="xsd:string"/> </xsd:sequence> </xsd:element> <xsd:element name="signaturewithcertificate"> <xsd:complextype> <xsd:choice> <xsd:element name="base64signature" type="xsd:base64binary"/> <xsd:element ref="ds:signature"/> <xsd:element name="signaturereference"> <xsd:documentation xml:lang="es"> Internal reference to file containing signature. </xsd:documentation> </xsd:element> </xsd:choice> </xsd:element> </xsd:choice> </xsd:element> </xsd:sequence> <xsd:attribute name="id" type="xsd:id" use="optional"/> <xsd:attribute name="ref" type="xsd:string" use="optional"> <xsd:documentation xml:lang="es">it stores the identifier of the node being signed. For multi-node signatures, a comma-separated list must be added of the identifiers of the signed nodes. </xsd:documentation> </xsd:attribute> </xsd:schema>
22 OFFICIAL STATE GAZETTE III. OTHER PROVISIONS MINISTRY OF TERRITORIAL POLICY AND PUBLIC ADMINISTRATION Resolution of the Secretary of State for Public Service, of 19 July 2011, giving approval to the Technical Interoperability Standard for E-Files. The National Interoperability Framework, established in Article 42, Section 1, of Law 11/2007, of 22 J une, on Citizens E-Access to Public Services, is aimed at creating the conditions necessary to guarantee an adequate level of technical, semantic and organisational interoperability of the systems and app lications used in the Public Administration, allowing the exercise of rights and the fulfilment of obligations through e- access to public services, while acting in the interest of effectiveness and efficiency. Royal Decree 4/2010, of 8 January, regulating the National Interoperability Framework for E-Government, establishes in Additional Provision 1 t he development of a series of Technical Interoperability Standards, which must be complied with in the Public Administration. The Technical Interoperability Standards describe specific aspects of a wide range of topics such as e-documents, digitisation, e-files, authentic copy and conversion, signature policy, standards, data brokerage, data models, e-document management, connection to the communication network of the Spanish Public Administration, and data models for the exchange of registry entries and declarations of conformity, all of which are necessary to guarantee the more practical and operational aspects of interoperability between Public Administration agencies and citizens. The Technical Interoperability Standards shall be further developed and improved over time, parallel to the progress of e-government services, their supporting infrastructure, and the evolution of technology, in order to meet the provision in Article 42.3 of Law 11/2007, of 22 June. Within the Technical Interoperability Standards, those related to e-documents, e-files, the digitisation of paper documents, authentic copy and conversion procedures, and e- document management policy are in accordance with the provisions in the aforementioned Royal Decree 4/2010, of 8 January, on the Interoperability, Retrieval and Preservation of E-Documents, in light of the need to guarantee these aspects for e- documents throughout their lifecycle. In particular, the Technical Interoperability Standard for E-Files describes the structure of e-files, including e-documents, e-indexes, e-signatures, and m inimum required metadata, and the specifications to send them and make them available. For e-file management and pr eservation issues, this Standard cross-refers to the Technical Interoperability Standard for E-Document Management Policy. Finally, the Annexes to this Resolution contain a detailed definition of the minimum required metadata and XML schemas for file exchange. In this regard, the e-file structure as defined in this Standard allows the use of e-signatures as envisaged in the Commission Decision 2011/130/EU, of 25 February, 2011, establishing minimum requirements for the cross-border processing of documents signed electronically by competent authorities under Directive 2006/123/EC of the European Parliament and of the Council on services in the internal market.
23 Drafted in collaboration with all the Public Administration agencies to which it applies, the present Technical Standard has received a favourable report from the Standing Committee of the High Council for E-Government, at the proposal of the E-Government Sector Committee. In accordance with the provisions in Section 2 of Additional Provision 1 of Royal Decree 4/2010, of 8 January, the Secretary of State decides: One To approve the Technical Interoperability Standard for E-Files whose text appears below. Two That the Technical Interoperability Standard for E-Files that is being approved by virtue of this document shall come into force on t he day following its publication in the Official State Gazette, irrespective of the clauses in Transitory Provision 1 of Royal Decree 4/2010, of 8 J anuary, regulating the National Interoperability Framework for E- Government. Madrid, 19 July, Secretary of State for Public Service María Consuelo Rumí Ibáñez. TECHNICAL INTEROPERABILITY STANDARD FOR E-FILES Contents I. Purpose I. Scope of application II. Components of e-files III. Metadata of e-files IV. Exchange of e-files Annex I. Minimum required metadata of e-files Annex II. XML schemas for e-file exchange I. Purpose The Technical Interoperability Standard for E-Files is intended to establish the structure and format of e-files, as well as the specifications of the services to send them and make them available. II. Scope of application II.1 This standard shall apply to e-files within the scope established in Article 3 of Royal Decree 4/2010, of 8 January, regulating the National Interoperability Framework for E-Government. II.2 The specifications set forth in this Standard can be applied to other sets of e- documents which, having been created under no regulated procedures, are the result of a series of coherent actions leading to a specific outcome. III.1 The components of e-files are: III. Components of e-files a) E-documents, which shall comply with the structure and format specifications in the Technical Interoperability Standard for E-Documents. E-documents can be pa rt of e-files as independent elements or in folders, the
24 latter being sets of e-documents created for functional purposes, or as part of another file, embedded in the former. b) E-indexes which, according to the provisions in Article 32.2 of Law 11/2007, of 22 June, shall guarantee the integrity of e-files and their retrieval whenever necessary. E-indexes shall contain the whole set of e-documents associated with a file at a given moment and, if necessary, their distribution in folders or files. c) E-index signature by the Public Administration, body or intervening agency, in accordance with regulations in force. d) Metadata. III.2 The addition of an e -file to a document management system shall comply with the provisions in the Technical Interoperability Standard for E-Documents and the Technical Interoperability Standard for E-Document Management Policy. IV.1 The minimum required metadata of e-files: a) Shall be those in Annex I. IV. Metadata of e-files b) Shall be associated during e-file creation for sending e-files and making them available. c) Shall not be altered at any stage of the administrative procedures, except for changes that need to be introduced to correct errors or omissions in the values originally assigned. IV.2 Complementary metadata can be added in response to special description needs. When necessary, complementary metadata shall be applied in compliance with the provisions in the Technical Interoperability Standard for E-Document Management Policy. V. Exchange of e-files V.1 The exchange of e-files for sending them or making them available shall consist in sending the structure described in Annex II first, without precluding others set out in the corresponding regulations. Once the structure has been sent, each of the e-documents in the e-file shall be sent in the established order and in compliance with the Technical Interoperability Standard for E-Documents. V.2 As an exception, other structures can be used to exchange e-files between Public Administration agencies if the parties have agreed on such structures beforehand. In any case, e-files that must be sent to third parties must be converted by the sender to the structure defined in Annex II. V.3 When the nature or the size of the evidence or documents in the e-file make it difficult to fit in the established structures, a document shall be added specifying which are such documents or evidence. They shall be kept in custody by the managing body and provided separately if required. V.4 The e-index of the files being exchanged shall at least contain: a) The date of index creation. b) For each e-document, the identifier, digital footprint, summary function used to create them in compliance with the provisions in the Technical Interoperability Standard
25 for Catalogue of Standards, and optionally the date when and the order in which they were added to the file. c) If relevant, the distribution of documents in folders and the hierarchy of nested files. V.5 For the exchange of e-files between Public Administration agencies in automated processes: a) The Public Administration communication network should preferably be used as the means of file transfer. b) If the e-file is part of a registry entry, it shall be treated as an attachment to the exchange data message, in compliance with the Technical Interoperability Standard for Data Models for the Exchange of Registry Entries. V.6 In case of e-document exchanges between Public Administration agencies involving the transfer of permanent document management responsibilities, the transferor shall check the document s authenticity and integrity at the moment when the exchange takes place.
26 ANNEXES ANNEX I Minimum required metadata of e-files Metadata Description/Terms of use Repeatability 1F 1 Type Value schema NTI version Standard identifier of the version of the Technical Interoperability Standard for E-Files (NTI) according to which the e-file is structured. 1 URI Identifier Standard identifier of the e-file. 1 Character string Body Standard identifier of the agency in charge of the procedure/ 1:N Character string ES_<BodyUU>_<AAAA>_EXP_<Specific_ID >2F 2 Example: ES_E _2010_EXP_ MPR A single alphanumeric code for each body/unit/office extracted from the Common Directory managed by the Ministry of Territorial Policy and Public Administration. UExampleU: E File opening date Date when the file is opened. 1 Date/time Format: AAAAMMDD T HH:MM:SS <ISO 8601> Classification Administrative procedure the file is associated with. 1 Character string Status File status at the moment of the exchange. 1 Character string Interested party Identifier of the interested party. 0:N Character string Standard value schema according to the System of Administrative Information (SIA). If the procedure cannot be found in SIA: <Body >_PRO_<Specific_ID_PRO >3F 3 - Open - Closed - Sending index closed a) If citizen or legal entity, ID/FIN/TIN or others. b) If Public Administration, <Body UU>. 1 In the table, repeatability refers only to the metadata accompanying a file in an exchange, irrespective of other metadata assigned and managed internally by each Public Administration agency in compliance with the Technical Interoperability Standard for E-document Management Policies. 2 E-document identifier encoding: <Body>: See encoding of Body metadata. If there is more than one body, the nine corresponding characters shall be agreed upon by the parties to ensure identifier uniqueness, which is their only purpose. <AAAA>: File creation year (4 characters). <Specific_ID>: Alphanumeric code uniquely identifying the document among those created by the relevant Public Administration agency. Each agency can design its own generation process according to its own needs as long as it ensures uniqueness. 3 Metadata encoding when the procedure is not found in SIA: <Body>: See encoding of Body metadata. <Specific_ID_PRO>: Alphanumeric code uniquely identifying the document among those created by the relevant Public Administration agency. Each agency can design its own generation process according to its own needs as long as it ensures uniqueness. Therefore, this ID can be generated in a sequence or be a replica of the ID used internally (30 characters).
27 Signature type Indication of the type of signature attached to the document. 1:N Character string For signature type = CSV CSV value Value of CSV. 1:N Character string - CSV. - E-signature formats for e-documents as defined in the Technical Interoperability Standard for Signature and Certification Policies in the Public Administration. N/A. CSV generation definition Reference to the decree, resolution, or document establishing the creation of the corresponding CSV. 1:N Character string For the General Administration (AGE): BOE (Official Spanish Gazette) reference: BOE-A-YYYY-XXXXX For others: corresponding reference.
28 ANNEX II XML schemas for e-file exchange 1. E-file XSD Legend: expediente: file indice: index metadosexp: FileMetadata VisualizaciónIndice: IndexView DatosXML: XMLData ValorBinario: BinaryValue referenciafichero: FileReference NombreFormato: FormatName <?xml version="1.0" encoding="utf -8"?> <xsd:schema xmlns:xsd=" xmlns:eniexpind=" xmlns:eniexpmeta=" xmlns:eniexp=" xmlns.enifile=
29 targetnamespace=" elementformdefault="qualified" attributeformdefault="unqualified"> <xsd:documentation xml:lang="es"> E-FILE XSD ENI (v1.0)</xsd:documentation> <xsd:import namespace=" schemalocation=" <xsd:import namespace=" schemalocation=" <xsd:import namespace=" schemalocation=" <xsd:element name="file" type="eniexp:filetype"/> <xsd:complextype name=" FileType"> <xsd:documentation>
30 For e-file exchange, first the file s index is sent. Then, the documents contained in the file, one by one, after the distribution in the index contents. </xsd:documentation> <xsd:sequence> <xsd:element ref="eniexpind:index"/> <xsd:element ref="eniexpmeta:metadataexp"/> <xsd:element name="indexview" type="enifile:contenttype" minoccurs="0" maxoccurs="1"/> </xsd:sequence> <xsd:attribute name="id" type="xsd:id" use="optional"/> </xsd:schema> 2. File e-index XSD Legend: Indice: index IndiceContenido: ContentIndex Firmas: signatures <?xml version="1.0" encoding="utf -8"?> <xsd:schema xmlns:xsd=" xmlns:enids=" xmlns:eniexpind=" xmlns:eniconexpind=" targetnamespace=" elementformdefault="qualified" attributeformdefault="unqualified"> <xsd:documentation xml:lang="es"> E-FILE INDEX XSD ENI (v1.0) </xsd:documentation> <xsd:import namespace=" schemalocation=" <xsd:import namespace=" schemalocation=" <xsd:element name="index" type="eniexpind:indextype"/> <xsd:complextype name="indextype"> <xsd:sequence> <xsd:element name="contentindex" type="eniconexpind:contentindextype"/> <xsd:element ref="enids:signatures">
31 <xsd:documentation>there must be at least one signature of the e-file index contents.</xsd:documentation> </xsd:element> </xsd:sequence> <xsd:attribute name="id" type="xsd:id" use="optional"/> </xsd:schema>
32 3. File e-index content XSD
33 Legend: IndiceContenido: ContentIndex FechaIndiceElectronico: E-IndexDate DocumentoIndizado: IndexedDocument IdentificadorDocumento: DocumentIdentifier ValorHuella: FootprintValue FuncionResumen: SummaryFunction FechaIncorporacionExpediente: FileAdditionDate OrdenDocumentoExpediente: FileDocumentOrder ExpedienteIndizado:IndexedFile FechaIndiceExpediente: E-IndexDate DocumentoIndizado: IndexedDocument ExpedienteIndizado: IndexedFile CarpetaIndizado: IndexedFolder CarpetaIndizada: IndexedFolder IdentificadorCarpeta: FolderIdentifier DocumetoIndizado: IndexedDocument ExpedienteIndizado: IndexedFile CarpetaIndizado: IndexedFolder <?xml version="1.0" encoding="utf -8"?> <xsd:schema xmlns:xsd=" xmlns:eniconexpind=" targetnamespace=" elementformdefault="qualified" attributeformdefault="unqualified"> <xsd:documentation xml:lang="es">e-file INDEX CONTENTS XSD ENI (v1.0) </xsd:documentation> <xsd:element name="contentindex" type="eniconexpind:contenindextype"/> <xsd:complextype name="contenindextype"> <xsd:sequence> <xsd:element name="e-indexdate" type="xsd:datetime"/> <xsd:choice maxoccurs="unbounded"> <xsd:element name="indexeddocument" type="eniconexpind:indexeddocumenttype"/> <xsd:element name="indexedfile" type="eniconexpind:contenindextype"/> <xsd:element name="indexedfolder" type="eniconexpind:indexedfoldertype"/> </xsd:choice> </xsd:sequence> <xsd:attribute name="id" type="xsd:id" use="optional"/> <xsd:complextype name="indexeddocumenttype"> <xsd:sequence> <xsd:element name="documentidentifier" type="xsd:string"/>
34 <xsd:element name="footprintvalue" type="xsd:string"/> <xsd:element name="summaryfunction" type="xsd:string"/> <xsd:element name="fileadditiondate" type="xsd:datetime" minoccurs="0"/> <xsd:element name="filedocumentorder" type="xsd:string" minoccurs="0"/> </xsd:sequence> <xsd:attribute name="id" type="xsd:id" use="optional"/> <xsd:complextype name="indexedfoldertype"> <xsd:sequence> <xsd:element name="folderidentifier" type="xsd:string"/> <xsd:choice maxoccurs="unbounded"> <xsd:element name="indexeddocument" type="eniconexpind:indexeddocumenttype"/> <xsd:element name="indexedfile" type="eniconexpind:contentindextype"/> <xsd:element name="indexedfolder" type="eniconexpind:indexedfoldertype"/> </xsd:choice> </xsd:sequence> <xsd:attribute name="id" type="xsd:id" use="optional"/> </xsd:schema>
35 4. E-file metadata XSD Legend: metadatosexp: FileMetadata VersionNTI: NTIVersion Identificador: Identifier Organo: Body FechaAperturaExpediente: FileOpeningDate Clasificacion: Classification Estado: Status Interesado: InterestedParty <?xml version="1.0" encoding="utf-8"?> <xsd:schema xmlns:xsd=" xmlns:eniexpmeta=" targetnamespace=" elementformdefault="qualified" attributeformdefault="unqualified"> <xsd:documentation xml:lang="es">e-file METADATA XSD ENI (v1.0) </xsd:documentation>
36 <xsd:element name="filemetadata" type="eniexpmeta:metadatatype"/> <xsd:complextype name="metadatatype"> <xsd:sequence> <xsd:element name="ntiversion" type="xsd:anyuri"/> <xsd:element name="identifier" type="xsd:string"/> <xsd:element name="body" type="xsd:string" minoccurs="1" maxoccurs="unbounded"/> <xsd:element name="fileopeningdate" type="xsd:datetime"/> <xsd:element name="classification" type="xsd:string"/> <xsd:element name="status">
37 <xsd:documentation xml:lang="es"> - E01 - Open. - E02 - Closed. - E03 - Sending index closed. </xsd:documentation> <xsd:complextype> <xsd:simplecontent> <xsd:extension base="eniexpmeta:statuslist"/> </xsd:simplecontent> </xsd:element> <xsd:element name="interestedparty" type="xsd:string" minoccurs="0" maxoccurs="unbounded"> <xsd:documentation xml:lang="es">required field when there is at least one interested party.</xsd:documentation> </xsd:element> </xsd:sequence> <xsd:attribute name="id" type="xsd:id" use="optional"/> <! File Status List --> <xsd:simpletype name="statuslist"> <xsd:restriction base="xsd:string"> <xsd:enumeration value="e01"/> <xsd:enumeration value="e02"/> <xsd:enumeration value="e03"/> </xsd:restriction> </xsd:simpletype> </xsd:schema>
38 5. Signature XSD Legend: firmas: signatures firma: signature TipoFirma: SignatureType ContenidoFirma: SignatureContent CSV: CSV ValorCSV: CSVValue RegulacionGeneracionCSV: CSVGenerationRegulation FirmaConCertificado: SignatureWithCertificate FirmaBase64: Base64Signature Firma: Signature ReferenciaFirma: SignatureReference <?xml version="1.0" encoding="utf-8"?> <xsd:schema xmlns:xsd=" xmlns:enids=" xmlns:ds=" targetnamespace=" " elementformdefault="qualified" attributeformdefault="unqualified"> <xsd:documentation xml:lang="es">e-signature XSD ENI (v1.0)</xsd:documentation> <xsd:import namespace=" schemalocation="
39 <xsd:element name="signatures" type="enids:signatures"/> <xsd:complextype name="signatures"> <xsd:sequence> <xsd:element name="s" type="enids:e-signaturetype" minoccurs="1" maxoccurs="unbounded"/> </xsd:sequence> <xsd:complextype name="e-signaturetype"> <xsd:sequence> <xsd:element name="signaturetype"> <xsd:documentation xml:lang="es"> - TF01 - CSV. - TF02 - XAdES internally detached signature. - TF03 - XAdES enveloped signature. - TF04 - CAdES detached/explicit signature. - TF05 - CAdES attached/implicit signature.
40 L. D.: M-1/ ISSN: X - TF06 - PAdES. </xsd:documentation> <xsd:simpletype> <xsd:restriction base="xsd:string"> <xsd:enumeration value="tf01"/> <xsd:enumeration value="tf02"/> <xsd:enumeration value="tf03"/> <xsd:enumeration value="tf04"/> <xsd:enumeration value="tf05"/> <xsd:enumeration value="tf06"/> </xsd:restriction> </xsd:simpletype> </xsd:element> <xsd:element name="signaturecontent"> <xsd:complextype> <xsd:choice> <xsd:element name="csv"> <xsd:complextype> <xsd:sequence> <xsd:element name="csvvalue" type="xsd:string"/> <xsd:element name="csvgenerationregulation" type="xsd:string"/> </xsd:sequence> </xsd:element> <xsd:element name="signaturewithcertificate"> <xsd:complextype> <xsd:choice> <xsd:element name="base64signature" type="xsd:base64binary"/> <xsd:element ref="ds:signature"/> <xsd:element name="signaturereference"> <xsd:documentation xml:lang="es"> Internal reference to file containing signature. </xsd:documentation> </xsd:element> </xsd:choice> </xsd:element> </xsd:choice> </xsd:element> </xsd:sequence> <xsd:attribute name="id" type="xsd:id" use="optional"/> <xsd:attribute name="ref" type="xsd:string" use="optional"> <xsd:documentation xml:lang="es">it stores the identifier of the node being signed. For multi-node signatures, a comma-separated list must be added of the identifiers of the signed nodes. </xsd:documentation> </xsd:attribute> </xsd:schema>
TECHNICAL INTEROPERABILITY STANDARD
TECHNICAL INTEROPERABILITY STANDARD For Document Digitisation. GOBIERNO DE ESPAÑA MINISTERIO DE HACIENDA Y ADMINISTRACIONES PÚBLICAS SECRETARÍA DE ESTADO DE ADMINISTRACIONES PÚBLICAS DIRECCIÓN GENERAL
<?xml version="1.0" encoding="utf-8"?> <xsd:schema xmlns:niso="http://www.niso.org/pdfs/datadict.pdf"
OFFICIAL STATE GAZETTE. No. 269 Tuesday, November 8, 2011 Section 1 Page 116296 I. GENERAL PROVISIONS MINISTRY OF THE PRESIDENCY
OFFICIAL STATE GAZETTE No. 269 Tuesday, November 8, 2011 Section 1 Page 116296 I. GENERAL PROVISIONS MINISTRY OF THE PRESIDENCY Royal Decree 1495/2011, of 24 th October 2011, whereby the Law 37/2007, of
Allegato XML flusso richieste di produzione
Allegato XML flusso richieste di produzione -
OFFICIAL STATE GAZETTE Nº 25 Friday 29 January 2010 Sect. I. Page 8139
OFFICIAL STATE GAZETTE Nº 25 Friday 29 January 2010 Sect. I. Page 8139 I. GENERAL PROVISIONS MINISTRY OF THE PRESIDENCY 1331 Royal Decree 4/2010, of January 8th, which regulates the National Interoperability
Comparison of IEC CIM and NRECA MultiSpeak
Lessons Learned Part 2: Business Vocabulary Management Comparison of IEC CIM and NRECA MultiSpeak Scott Neumann Partner, Chairman, USNC IEC TC57 1 MultiSpeak Background MultiSpeak effort funded by National
Parallels Operations Automation 5.4
Parallels Operations Automation 5.4 Migration Manager Developer's Guide Revision 5.8 (May 15, 2012) Copyright 1999-2012 Parallels IP Holdings GmbH and its affiliates. All rights reserved. Parallels IP
XML Based Customizable Screen. Rev 1.1
XML Based Customizable Screen Rev 1.1 August 10, 2006 1. Introduction Starting from release version 1.0.2.X, GXP-2000 supports the idle screen customization. The designs of the displayed information and
Selling on Amazon Guide to XML
Selling on Amazon Guide to XML Editor s Note The XML Help documentation contains general information about using XML on Amazon. There are differences in using XML for various Amazon websites, based on
How To Use The Mets Document In A Webmail Document In An Html File On A Microsoft Powerbook 2.5.2.1.1 (Html) On A Macbook 2 (Html).1.5 (Html2)
Příloha č. 3 národního standardu pro elektronické systémy spisové služby Schéma XML pro vytvoření datového balíčku SIP
Royal Decree 1671/2009, of 6 November, which partially develops Law 11/2007 of 22 June, regarding citizens electronic access to public services
Royal Decree 1671/2009, of 6 November, which partially develops Law 11/2007 of 22 June, regarding citizens electronic access to public services Gobierno de España. Ministerio de Política Territorial y
INTEGRATING WEB SERVICES INTO A WEB-BASED COLLEGE ADMISSION PORTAL SYSTEM
INTEGRATING WEB SERVICES INTO A WEB-BASED COLLEGE ADMISSION PORTAL SYSTEM Dr. Billy Lim, Yan Sun School of Information Technology Illinois State University Normal, IL 61790-5150, USA [email protected], [email protected]
Electronic Archive Information System
107 Electronic Archive Information System Saulius RAGAISIS a,1, Adomas BIRSTUNAS b, Antanas MITASIUNAS b and b Arunas STOCKUS a Software Engineering Department, Vilnius University, Lithuania b Computer
Geography Markup Language (GML) simple features profile
Open Geospatial Consortium Inc. Date: 2006-04-25 Reference number of this document: OGC 06-049 Version: 1.0 Category: OpenGIS Implementation Specification Profile Editor: Panagiotis (Peter) A. Vretanos
Device Feature Key Synchronization
Device Feature Key Synchronization Feature Description Release 14.sp2 Document Version 1.2 DeviceFeatureKeySynchronizationFD ExtraView Number 36498 9737 Washingtonian Boulevard, Suite 350 Gaithersburg,
EHR-IIS Interoperability Enhancement Project. Transport Layer Protocol Recommendation Formal Specification. Version 1.
EHR-IIS Interoperability Enhancement Project Transport Layer Protocol Recommendation Formal Specification Version 1.1 June 4, 2014 Transport Layer Expert Panel EHR-IIS Interoperability Enhancement Project
Introduction to XML. Data Integration. Structure in Data Representation. Yanlei Diao UMass Amherst Nov 15, 2007
Introduction to XML Yanlei Diao UMass Amherst Nov 15, 2007 Slides Courtesy of Ramakrishnan & Gehrke, Dan Suciu, Zack Ives and Gerome Miklau. 1 Structure in Data Representation Relational data is highly
XML Schema Definition Language (XSDL)
Chapter 4 XML Schema Definition Language (XSDL) Peter Wood (BBK) XML Data Management 80 / 227 XML Schema XML Schema is a W3C Recommendation XML Schema Part 0: Primer XML Schema Part 1: Structures XML Schema
Languages for Data Integration of Semi- Structured Data II XML Schema, Dom/SAX. Recuperación de Información 2007 Lecture 3.
Languages for Data Integration of Semi- Structured Data II XML Schema, Dom/SAX Recuperación de Información 2007 Lecture 3. Overview XML-schema, a powerful alternative to DTDs XML APIs: DOM, a data-object
How To Write A Contract Versioning In Wsdl 2.2.2
023_013613517X_20.qxd 8/26/08 6:21 PM Page 599 Chapter 20 Versioning Fundamentals 20.1 Basic Concepts and Terminology 20.2 Versioning and Compatibility 20.3 Version Identifiers 20.4 Versioning Strategies
The A2A Data Model and its application in WieWasWie. Michel Brinckman [email protected] @michelbrinckman
The A2A Data Model and its application in WieWasWie Michel Brinckman [email protected] @michelbrinckman Overview Archive documents vs genealogy Need for abstraction A2A Entities Into the XML syntax How
FICHE NO 6 IMPLEMENTING ACT ON THE RULES CONCERNING ELECTRONIC INFORMATION VERSION 2 4 JUNE 2013. Common Provisions Regulation [COM(2012) 496]
![FICHE NO 6 IMPLEMENTING ACT ON THE RULES CONCERNING ELECTRONIC INFORMATION VERSION 2 4 JUNE 2013. Common Provisions Regulation [COM(2012) 496]](/thumbs/39/19939208.jpg "FICHE NO 6 IMPLEMENTING ACT ON THE RULES CONCERNING ELECTRONIC INFORMATION VERSION 2 4 JUNE 2013. Common Provisions Regulation [COM(2012) 496]")
FICHE NO 6 IMPLEMENTING ACT ON THE RULES CONCERNING ELECTRONIC INFORMATION EXCHANGE WITH BENEFICIARIES ("E-COHESION") VERSION 2 4 JUNE 2013 Regulation Common Provisions Regulation [COM(2012) 496] Article
COMMISSION OF THE EUROPEAN COMMUNITIES
EN EN EN COMMISSION OF THE EUROPEAN COMMUNITIES Brussels, 28.11.2008 COM(2008) 798 final COMMUNICATION FROM THE COMMISSION TO THE COUNCIL, THE EUROPEAN PARLIAMENT, THE EUROPEAN ECONOMIC AND SOCIAL COMMITTEE
Exercises: XSD, XPath Basi di da4 2
Exercises: XSD, XPath Basi di da4 2 Disheng Qiu [email protected] Luca Rossi [email protected] Hints: Use a validator XSD Eclipse has a plugin for XML/XSD/DTD valida4on W3C Validator: hmp://www.w3.org/2001/03/webdata/xsv
DIRECTOR GENERAL OF THE LITHUANIAN ARCHIVES DEPARTMENT UNDER THE GOVERNMENT OF THE REPUBLIC OF LITHUANIA
Non-official translation DIRECTOR GENERAL OF THE LITHUANIAN ARCHIVES DEPARTMENT UNDER THE GOVERNMENT OF THE REPUBLIC OF LITHUANIA ORDER ON THE CONFIRMATION OF THE SPECIFICATION ADOC-V1.0 OF THE ELECTRONIC
How To Manage E-Documents In Lithuania
THE LIFE CYCLE OF E-DOCUMENTS: METHODOLOGICAL AND LEGAL APPROACH IN LITHUANIA DAIVA LUKŠAITĖ Head of Documents and Archives Management Divison E-mail [email protected] www.archyvai.lt THE LIFE CYCLE
Chapter 15 Working with Web Services
Section 3 Chapter 15: Working with Web Services 225 Chapter 15 Working with Web Services The next generation of Web applications involves the use of Web Services. Visual FoxPro 7 s new built-in XML capabilities
SSLPost Electronic Document Signing
SSLPost Electronic Document Signing Overview What is a Qualifying Advanced Electronic Signature (QAES)? A Qualifying Advanced Electronic Signature, is a specific type of digital electronic signature, that
XML-BASED AUTOMATIC TEST DATA GENERATION
Computing and Informatics, Vol. 27, 2008, 681 698 XML-BASED AUTOMATIC TEST DATA GENERATION Halil Ibrahim Bulbul Department of Computer Education Gazi University, Ankara, Turkey e-mail: [email protected]
TCG Trusted Network Connect. TNC IF-MAP Metadata for Network Security
TCG Trusted Network Connect TNC IF-MAP Metadata for Network Security Specification Version 1.0 Revision 25 13 September 2010 Published Contact: [email protected] TCG PUBLISHED Copyright TCG
<!--=========================================--> <!--=========================================-->
Send your request via a SOAP-Request (e.g. with DotNET/SOAP, Java, PHP) to he following URL of our server:
1 QualityClick SOAP-API Documentation 1.1 URI soap uri: soap proxy: ' ' https://www.qc-domain.de/iqx_downlink'; https://www.qc-domain.de/iqx_downlink_soap.cgi'; 1.2 Method Send your request via a SOAP-Request
Et tu, XML? Philip Wadler, Avaya Labs [email protected]
Et tu, XML? Philip Wadler, Avaya Labs [email protected] Acknowledgements This talk is joint work with: Mary Fernandez (AT&T) Jerome Simeon (Lucent) The W3C XML Query Working Group Disclaimer: This talk.
Multiple electronic signatures on multiple documents
Multiple electronic signatures on multiple documents Antonio Lioy and Gianluca Ramunno Politecnico di Torino Dip. di Automatica e Informatica Torino (Italy) e-mail: [email protected], [email protected] web
MAGERIT version 3.0 Methodology for Information Systems Risk Analysis and Management. Book I - The Method
MAGERIT version 3.0 Methodology for Information Systems Risk Analysis and Management Book I - The Method TITLE: MAGERIT version 3.0. Methodology for Information Systems Risk Analysis and Management. Book
Message Implementation Guidelines
C/ Santa María Magdalena 16, 28016 Madrid ICS Import Control System Message Implementation Guidelines Author: S.G.A.A Date: 17/01/2013 Release: 1.8 Ed. Rev. Date Description A(*) Pages 1 0 01/02/2010 Document
04 XML Schemas. Software Technology 2. MSc in Communication Sciences 2009-10 Program in Technologies for Human Communication Davide Eynard
MSc in Communication Sciences 2009-10 Program in Technologies for Human Communication Davide Eynard Software Technology 2 04 XML Schemas 2 XML: recap and evaluation During last lesson we saw the basics
Modernize your NonStop COBOL Applications with XML Thunder September 29, 2009 Mike Bonham, TIC Software John Russell, Canam Software
Modernize your NonStop COBOL Applications with XML Thunder September 29, 2009 Mike Bonham, TIC Software John Russell, Canam Software Agenda XML Overview XML Thunder overview Case Studies Q & A XML Standard
esignature building block Introduction to the Connecting Europe Facility DIGIT Directorate-General for Informatics
Introduction to the Connecting Europe Facility esignature building block DIGIT Directorate-General for Informatics DG CONNECT Directorate-General for Communications Networks, Content and Technology February
Java and XML parsing. EH2745 Lecture #8 Spring 2015. [email protected]
Java and XML parsing EH2745 Lecture #8 Spring 2015 [email protected] Lecture Outline Quick Review The XML language Parsing Files in Java Quick Review We have in the first set of Lectures covered the basics
Submitted to the EC on 03/06/2012. COMPETITIVENESS AND INNOVATION FRAMEWORK PROGRAMME ICT Policy Support Programme (ICT PSP) e-codex
Submitted to the EC on 03/06/2012 COMPETITIVENESS AND INNOVATION FRAMEWORK PROGRAMME ICT Policy Support Programme (ICT PSP) e-codex e-justice Communication via Online Data Exchange ICT PSP call identifier:
Explanatory notes VAT invoicing rules
Explanatory notes VAT invoicing rules (Council Directive 2010/45/EU) Why explanatory notes? Explanatory notes aim at providing a better understanding of legislation adopted at EU level and in this case
Questions & Answers. on e-cohesion Policy in European Territorial Cooperation Programmes. (Updated version, May 2013)
Questions & Answers on e-cohesion Policy in European Territorial Cooperation Programmes (Updated version, May 2013) This fact sheet was drafted jointly by INTERACT and European Commission (DG Regional
Table of Contents. Chapter No. 1. Introduction 1. 2. Objective 1. 3. E-mail Use Compliance 1. 4. Definitions 2. 5. Roles and Responsibilities 2
Table of Contents Chapter Subject Page No. 1. Introduction 1 2. Objective 1 3. E-mail Use Compliance 1 4. Definitions 2 5. Roles and Responsibilities 2 6. Creation and Use of E-mails 3 7. Managing E-mails
Code of Practice on Electronic Invoicing in the EU
CEN/WS einvoicing Phase 3 Date: 2011-11 CEN Workshop AgreementTC WI Secretariat: NEN Code of Practice on Electronic Invoicing in the EU Status: for public review (23 November 2011-23 January 2012) ICS:
e-justice in Hungary Ferenc Zombor Deputy State Secretary Responsible for EU and International Justice Cooperation
e-justice in Hungary Ferenc Zombor Deputy State Secretary Responsible for EU and International Justice Cooperation PRESENTATION OUTLINE I. Historic and Legal Background II. The Act on e-signatures III.Electronic
Designing the Service Contract
Designing the Service Contract Service contracts provide the glue that enables us to assemble disparate pieces of software or services into complete, composite applications. If we are to build a sustainable
ETSI TS 102 778 V1.1.1 (2009-04) Technical Specification
TS 102 778 V1.1.1 (2009-04) Technical Specification Electronic Signatures and Infrastructures (ESI); PDF Advanced Electronic Signature Profiles; CMS Profile based on ISO 32000-1 2 TS 102 778 V1.1.1 (2009-04)
Queensland recordkeeping metadata standard and guideline
Queensland recordkeeping metadata standard and guideline June 2012 Version 1.1 Queensland State Archives Department of Science, Information Technology, Innovation and the Arts Document details Security
European Commission DIRECTORATE GENERAL. European Commission, B-1049 Brussels Belgium, Telephone: (32-2) 299 11 11
European Commission DIRECTORATE GENERAL DIGIT E-TrustEx for e-cohesion - Vision European Commission, B-1049 Brussels Belgium, Telephone: (32-2) 299 11 11 Original Template Author: DIGIT.01.MIA Version
NIST-Workshop 10 & 11 April 2013
NIST-Workshop 10 & 11 April 2013 EUROPEAN APPROACH TO OVERSIGHT OF "TRUST SERVICE PROVIDERS" Presented by Arno Fiedler, Member of European Telecommunications Standards Institute Electronic Signatures and
U.S. FDA Title 21 CFR Part 11 Compliance Assessment of SAP Records Management
U.S. FDA Title 21 CFR Part 11 Compliance Assessment of SAP Records Management Disclaimer These materials are subject to change without notice. SAP AG s compliance analysis with respect to SAP software
GeoSciML Cookbook. How to serve a GeoSciML version 2 Web Feature Service (WFS) using Open Source Software. Version 1.2-1 -
GeoSciML Cookbook How to serve a GeoSciML version 2 Web Feature Service (WFS) using Open Source Software Version 1.2-1 - Contents 1 IN TRODUCTION... - 3-1.1 The purpose of this cookbook... - 3-1.2 Who
No Trade Secrets. Microsoft does not claim any trade secret rights in this documentation.
[MS-EDCSOM]: Intellectual Property Rights Notice for Open Specifications Documentation Technical Documentation. Microsoft publishes Open Specifications documentation for protocols, file formats, languages,
1. What is Long-Term Docs... 5
Contents 1. What is Long-Term Docs... 5 1.1. General Properties of Long-Term Docs... 5 1.2. The Features of Long-Term Docs... 5 1.2.1. Long-Term Document Validity (LTV)... 6 1.2.2. Long-Term Document Archiving
Francesco Tortorelli
Francesco Tortorelli Joint CEN/TC 287 and OGC Workshop Bringing GI Standards-making bodies together Frascati (Rome), 30 September 2013 (AgID) AgID (previously CNIPA and DigitPA) is a government agency
How To Write A Book On The Digital Age Of Science
New Trends in Digital University Libraries Peter Schirmbacher * Introduction When speaking about trends in university digital libraries it is necessary to concentrate on the main points and discuss only
Record Retention and Digital Asset Management Tim Shinkle Perpetual Logic, LLC
Record Retention and Digital Asset Management Tim Shinkle Perpetual Logic, LLC 1 Agenda Definitions Electronic Records Management EDMS and ERM ECM Objectives Benefits Legal and Regulatory Requirements
JUAN CARLOS I KING OF SPAIN
19814 LAW 37/2007 of 16 November 2007 on the re-use of public sector information JUAN CARLOS I KING OF SPAIN To all who see and understand this document. Be it known: That the Spanish Parliament has approved
Software Developer s Guide for the Cisco Secure Access Control System 5.1
Software Developer s Guide for the Cisco Secure Access Control System 5.1 Americas Headquarters Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 USA http://www.cisco.com Tel: 408 526-4000
STANDARDISIERUNG FÜR EIDAS IM MANDATE/460
STANDARDISIERUNG FÜR EIDAS IM MANDATE/460 TeleTrusT Signaturtag 17.09.2015 ETSI 2014. All rights reserved STANDARDISIERUNG FÜR EIDAS IM MANDATE/460 TeleTrusT Signaturtag 17.09.2015 ETSI 2014. All rights
ETSI SECURITY WEEK EIDAS Overview CEN/ETSI esignature Standardization including standards for TSP Compliance. ETSI 2015. All rights reserved
ETSI SECURITY WEEK EIDAS Overview CEN/ETSI esignature Standardization including standards for TSP Compliance esignature Standards Framework Certificate Authority Time-stamping Signing Servers Validation
This document is no longer current. Please go to the following URL for more information:
This document is no longer current. Please go to the following URL for more information: http://www.nationalarchives.gov.uk/electronicrecords/reqs2002/default.htm Requirements for Electronic Records Management
Fairsail. Implementer. Fairsail to Active Directory Synchronization. Version 1.0 FS-PS-FSAD-IG-201310--R001.00
Fairsail Implementer Fairsail to Active Directory Synchronization Version 1.0 FS-PS-FSAD-IG-201310--R001.00 Fairsail 2013. All rights reserved. This document contains information proprietary to Fairsail
OMG ARAP --The MDA Approach to to a Finance Web Service
OMG ARAP --The MDA Approach to to a Finance Web Service Arne J. Berre, SINTEF ([email protected]) Todd Boyle, Morten Jacobsen, Netaccount ([email protected], [email protected]) OMG GL
IAM Application Integration Guide
IAM Application Integration Guide Date 03/02/2015 Version 0.1 DOCUMENT INFORMATIE Document Title IAM Application Integration Guide File Name IAM_Application_Integration_Guide_v0.1_SBO.docx Subject Document