Format Conversion Service Specification v1.7-EIG

8/6/2019 Format Conversion Service Specification v1.7-EIG

http://slidepdf.com/reader/full/format-conversion-service-specification-v17-eig 1/22

1/22

FP6-511678

ORCHESTRA

Open Architecture and Spatial Data Infrastructure forRisk Management

Integrated Project

Priority 2.3.2.9 Improving Risk Management

WP3.4 – OA Service Specifications

Specification of the Format Conversion Service

Revision [1.7 / 2.2.2]



Specification of the Format Conversion Service – Document Control Page

2/22

Document Control Page

Title Specification of the Format Conversion Service

Creator Fischer, Julian Environmental Informatics Group

Subject WP3.4 – OA Service Specifications

Description This document defines an abstract and platform independent formalspecification of the Format Conversion Service.

Publisher ORCHESTRA consortium

Contributor Berlinghoff, Thomas Environmental Informatics Group

Dihé, Pascal Environmental Informatics Group

Fischer, Julian Environmental Informatics Group

Hofmann, Thomas Environmental Informatics Group

Iosifescu-Enescu, Ionut ETH Zurich

Ma, Wenjie Environmental Informatics Group

Date 2006-07-26

Type Text

Format application/msword

Identifier http://portal.opengeospatial.org/files/?artifact_id=12098

Source Not applicable

Language en-GB.

Relation none

Coverage ORCHESTRA Consortium and restricted audience

Rights

Deliverable number D3.4.3

Work-Package contribut-ing to the Deliverable

WP3.4

Contractual Date of De-livery

2006-06-30

Actual Date of Delivery 2006-07-28

Audience public

restricted

internal

Version number 1.7 / 2.2.2

Date 2007-10-08

Modified by Ma, Wenjie Environmental Informatics Group

Comments Intended for incorporation in deliverable 3.4.4



Specification of the Format Conversion Service – Document Control Page

3/22

Status Draft

WP leader accepted

SP leader acceptedTechnical supervisor accepted

Quality checked

Project coordinator accepted

Action requested to be revised by partners involved in the preparation of the deliver-able

for approval of the WP leader

for approval of the SP leader

for approval of the Technical Supervisor

for approval of the Quality Manager

for approval of the Project Coordinator

Deadline for action: 2006-07-28



Specification of the Format Conversion Service – Revision History

4/22

Revision History

Revision Date Sections changed Description

1.0 2005-09-02 all 1st

intermediate release

1.1 2005-09-24 all updated to new template structure

1.1.1 2006-01-05 all Minor updates

1.2 / 1.7 2006-02-06 all Add Document Control Page, section Confor-mance and Annex D: Abstract test suite,changes on headline in some sections.

1.3 / 1.7 2006-02-09 all Final version after ETHZ review

1.3.1 / 1.7 2006-02-21 1.2, 5.1 Update of class diagrams

1.4 / 1.7 2006-02-23 all Operation getConversionCapabilities deleted

1.5 / 2.0.5 2006-06-26 all Adoption to template 2.0.5, completion of miss-ing sections. Removal of chapter “6 Appendix A:Service Implementation Recommendation”

1.6 /2.0.6 2006-08-08 some Comments resolved; update to template 2.0.6

1.7 / 2.2.2 2007-10-08 all updated to new template structure





Specification of the Format Conversion Service – Table of Contents

6/22

8.1.2 Cooperation and Cascading between Service Instances ..........................................................19 9 Appendix A: Abstract Test Suite (normative)............................................................................................21 10 Appendix B: UML Models (normative) ......................................................................................................22

10.1 XMI Model ......................................................................................................................................22



Specification of the Format Conversion Service – Tables and Diagrams

7/22

Tables

Table 1: Summary of operation........................................................................................................................13 Table 2: Referenced OA Types .......................................................................................................................15

Table 3: Specification of the convert Operation...............................................................................................16 Table 4: Sections of the service specific capabilities.......................................................................................17 Table 5 Attributes of the service specific capabilities of section availableOrdinaryConversions .................... 18

Diagrams

Diagram 1: Class Diagram of the Format Conversion Service........................................................................10 Diagram 2: Class Diagram of the Format Conversion Interface......................................................................13

Diagram 3 Format Conversion Service specific capabilities............................................................................ 17





Specification of the Format Conversion Service – Conventions

9/22

2 Conventions

2.1 Abbreviations

The abbreviations used in this document are defined in chapter 3.1 of the Reference Model for theORCHESTRA Architecture Version 2.0 (RM-OA).

2.2 Terms and definitions

Terms and definitions necessary for understanding this document are defined in chapter 3.2 of the RM-OA Glossary.

2.3 UML Notation

All diagrams that appear in this specification are presented using the Unified Modelling Language(UML) version 2.0 as the conceptual schema language.

2.4 Conformance

2.4.1 Conformance to the OMM

This abstract service specification is specified according to the rules of the ORCHESTRA Service Meta-model (OMM-Service) and follows the rules for ORCHESTRA Services as described in chapter 9.2 ofthe RM-OA.

The extended service capabilities are be modelled according to the RM-OA rules for OAS-MI.

2.4.2 Conformance of Implementation Specifications

Conformance of Implementation Specifications to this Abstract Specification shall be checked using allthe relevant tests and rules specified or referenced in Appendix A: Abstract Test Suite (normative).



Specification of the Format Conversion Service – Overview and Architecture Outline

10/22

3 Overview and Architecture Outline

3.1 Role and Scope of the Format Conversion Service

The Format Conversion Service allows the conversion of data given in one format to the correspondingdata given in another format. Each conversion between a pair of formats requires a conversion algo-rithm.

The problem we face is how two organisations are able to exchange their documents without caringabout the format the other side uses. This is the reason why the “Format Conversion Service” isneeded. It allows the conversion from one document type (MS-Word, OpenDocument, pdf, …) to an-other one in order to easily exchange documents between different organisations. Data could be textbased, like a word document or a pdf, or it could be binary data like JPEG or WMF.

3.2 Service Interface Specification Summary

This service type specification of the Format Conversion Service is comprised of the following interfacethat is defined in separate interface type specification:

• The Service Capabilities Interface Type

The following interface is specified as integral part of this service in chapter 6:

• The Format Conversion Interface Type

cd Format Conversion Service - Overview

«interface»

ServiceCapabilities

+ getCapabilities(OA_GetCapabili tiesRequest) : OA_GetCapabilitiesResponse

FormatConversionInterface

«interface»

FormatConversionService

+ convert(OA_MimeType, OA_MimeType, OA_File) : OA_Fil e

+ getCapabilities(OA_GetCapabili tiesRequest) : OA_CapabilitiesDocument

Diagram 1: Class Diagram of the Format Conversion Service



Specification of the Format Conversion Service – Context of the Format Conversion Service

11/22

4 Context of the Format Conversion Service

4.1 Relations to Standards

The way used to specify the format or type is established according to MIME (RFC 2387), a list ofavailable types is maintained at IANA.

The MIME-standard is available as RFC 2387 at:

http://www.ietf.org/rfc/rfc2387.txt

See for available types at:

http://www.iana.org/assignments/media-types/

Depending on the requirements of actual applications, the resulting implementation of the Format Con-version Service can adopt different standards. These might be file formats for pictures, e.g.:

• Portable Network Graphics (PNG) [W3C-PNG: http://www.w3.org/TR/PNG/ and ISO/IEC15948:2003]

• JPEG (lossy and lossless: ITU-T T.81, ISO/IEC IS 10918-1; extensions: ITU-T T.84)

• JPEG-LS (lossless: ITU-T T.87, ISO/IEC IS 14495-1)

• JBIG (black and white: ITU-T T.82, ISO/IEC IS 11544-1)

• JPEG-2000 (evolved from JPEG/JPEG-LS: ITU-T T.800, ISO/IEC IS 15444-1; extensions: ITU-T T.801)

• Scalable Vector Graphics (SVG) [http://www.w3.org/Graphics/SVG/]

• ArcView Shapefile

•

…Hints:

• a list of picture file formats may be found at:http://en.wikipedia.org/wiki/Graphics_file_format_summary

• a converter from “ArcView Shapefile” to SVG is available under the terms of the LGPL at:http://www.carto.net/papers/svg/utils/shp2svg/

Standard file formats for textual documents might be:

• RTF (various Microsoft™ specifications)

• OpenDocument (OASIS Open Document Format for Office Applications; ISO/IEC DIS 26300)

•

Microsoft™ Word documents• …

The Format Conversion Service currently does not qualify for the contribution to a standard.

4.2 Relations to ongoing Initiatives and related Projects

The Format Conversion Service has no immediate relation to ongoing projects.

4.3 Relations to ORCHESTRA Application Schemas

The Format Conversion Interface Type Specification that is specified as integral part of this ServiceType Specification uses Basic and OA Types that are defined in the package OAS/Basic Types,

OAS/OA Types and OAS-MI/OA-MI Types of the Information Viewpoint.



Specification of the Format Conversion Service – Context of the Format Conversion Service

12/22

The Format Conversion Interface Type Specification that is specified as integral part of this ServiceType Specification defines new parameter types.

• These parameter types are defined the in the package OAS/OA Types/«Application Schema»Format Conversion Service Exceptions, OAS/OA Types/ «Application Schema» Format Con-

version Service Types of the Information Viewpoint.

4.4 Relations to other ORCHESTRA Service Specifications

The interaction with the Document Access Service is a possible relation to the OA Service. The modeof interaction is to be defined in the respective service’s specification.



Specification of the Format Conversion Service – Requirements

13/22

5 Requirements

5.1 Security Requirements

The Format Conversion Service has no requirements beyond the scope of the Authentication and Au-thorisation Service.

5.2 Reliability Requirements

• The question about the technical possibility of a certain conversion will be answerable using thegetCapabilities operation. If a certain possible conversion will deliver the expected result is adifferent question.

• Consider the conversion of a document given in the format with the mime-type “text/html” thathas to be converted to “text/plain”. Sloppy spoken the conversion includes parsing the html-document, stripping the html-tags and finally produce a reasonable formatted text-file. But find-

ing an algorithm which performs reasonable formatting for an arbitrary html-document is quitehard. Consider the following algorithm: Replace every html-tag with a single space. This willsatisfy our requirement converting from “text/html” to “text/plain” but will lead to a huge andhardly readable text. Of course there are many better approaches to do that conversion but thebasic problem becomes clear. Two “text/html” to “text/plain” conversion-adapters may be fairlydifferent. Their use has to be considered in the context of their purpose to really ensure ameaningful outcome.

6 Specification of the Format Conversion Interface

cd Format Conversion Interface

«interface»

FormatConversionInterface

+ convert(OA_MimeType, OA_MimeType, OA_File ) : OA_File

Diagram 2: Class Diagram of the Format Conversion Interface

The Format Conversion Interface defines the following operation:

Operation Name Description

convert Performs the conversion given by input and output mime type.

Table 1: Summary of operation



Specification of the Format Conversion Service – Conformance of Implementation Specifications

14/22

6.1 Specification of an OAS Profile of Parameter Types used by the Format Con-version Interface

The following non basic types are used within this specification:

Name Usage from OAS New

OA_File I, O OA Types No

OA_MimeType I, O OA Types No

OA_CapabilitiesDocument O OA Types No

OA_UnknownMimeTypeException E OA Types/Exception Types Yes

OA_InvalidInputFileException E OA Types/Exception Types Yes

OA_ConversionNotSupportedException E OA Types/Exception Types Yes

OA_GetCapabilitiesRequest I OA Types No

OA_OperationRequest I OA Types No

OA_NotificationCallback I OA Types No

OA_OperationResponse O OA Types No

OA_Notification I OA Types No

OA_OperationResult O OA Types No

OA_InvokeID O OA Types No

OA_VersionNegotiationFailed E OA Types/Exception Types No

OA_UnsupportedSchema E OA Types/Exception Types No

OA_InvalidParameterValue E OA Types/Exception Types No

OA_MissingParameterValue E OA Types/Exception Types No

OA_NoApplicableCode E OA Types/Exception Types No

OA_InternalError E OA Types/Exception Types No

OA_VersionNegotiationFailed E OA Types/Exception Types No



Specification of the Format Conversion Service – Specification of the convert Operation

15/22

OA_UnsupportedSchema E OA Types/Exception Types No

OA_SyncOperationUnsupported E OA Types/Exception Types No

OA_OperationFailure E OA Types/Exception Types No

OA_AsyncOperationUnsupported E OA Types/Exception Types No

OA_AbortNotPossible E OA Types/Exception Types No

OA_InvalidStat E OA Types/Exception Types No

Table 2: Referenced OA Types

6.2 Specification of the Operations

6.2.1 Specification of the convert Operation

The mandatory convert operation converts data. This data is provided via an input-file, the format of theinput-file is specified via a parameter, and the same applies for the output-file.

The signatures of the operation is

OA_File convert (OA_MimeType, OA_MimeType, OA_File) throws OA_InvalidParameterValue,OA_MissingParameterValue, OA_NoApplicableCode, OA_InternalError,OA_UnknownMimeTypeException, OA_InvalidInputFileException,OA_ConversionNotSupportedException

Overrides not applicable

Preconditions none

Post condi-tions

none

Use Mandatory

Name Type Use Description

outputFormat OA_ mandatory Mime-type the output-fileshall have

inputFormat OA_MimeType mandatory Mime-type the input-file has

Receives

inputFile OA_File mandatoryThe reference to the input-file

Type DescriptionReturns

OA_File The converted file

Throws Type Cause



Specification of the Format Conversion Service – OA_UnknownMimeTypeException

16/22

OA_InvalidParameterValue Operation request contains an invalid pa-rameter value. Return the name of theparameter with invalid value.

OA_MissingParameterValue Operation request does not include a pa-rameter value. Return the name of themissing parameter

OA_NoApplicableCode No other basic or service-specific excep-tion type applies.

OA_InternalErrorA problem occurred in the runtime envi-ronment (e.g. out of memory)

OA_UnknownMimeTypeExceptionIn case a format specified as one of theparameters is not known to this serviceinstance.

OA_InvalidInputFileException The specified input-file in not valid. Pos-sible reasons are: not found, or the for-mat does not comply to the specified one.

OA_ConversionNotSupportedExceptionThe conversion between the specified in-put-format and the output-format is notsupported.

Table 3: Specification of the convert Operation

6.3 Specification of Parameter Types

This interface specification defines the OA Types

These new OA Types will become part of the OAS “OA Types”.

This interface specification does not define any new OT Types.

This interface specification does not introduce any new non-ORCHESTRA Types.

6.3.1 OA_UnknownMimeTypeException

In case a format specified as one of the parameters is not known to this service instance.

6.3.2 OA_InvalidInputFileException

If the specified input-file in not valid, the possible reason are: not found, or the format does not complywith the specified one.

6.3.3 OA_ConversionNotSupportedException

The conversion between the specified input-format and the output-format is not supported by this in-stance of the Format Conversion Service.



Specification of the Format Conversion Service – Specification of Parameter Types

17/22

7 Specification of extended Service Capabilities

As part of ORCHESTRA D3.3.2 a meta-information schema for services is defined acting as a default

OAS-MI for service capabilities. OA_MI_CapabilitiesDocument includes both the common capabilitiesand the service specific capabilities. While the common capabilities are defined in the specification ofthe Service Capabilities Interface, the specific capabilities have to be specialized in each service speci-fication.

cd Format Conversion Serv ice Capabilities

OA_MI_Service_SpecificCapabilities

«type»

OA_FormatConv ersionCapabilities

list

+ avail able OrdinaryConversions: OA_ConversionIn formation

«type»

OA_MI_FCS_SpecificCapabilities

+ isLossy: Boo lean

«type»

OA_ConversionInformation

+ input: OA_MimeT ype

+ output: OA_MimeT ype

Specialisation/decoration

with "isLossy",

"isAdapterChain" and so

on needs to be rethought.

Diagram 3 Format Conversion Service specific capabilities

The schema for service specific capabilities defined here is explicitly divided into the following schemasections:

Section Name Section Contents

availableOrdinaryConversions List of conversions that can be done with using a single conversion algorithm. Each ConversionInformation object represents a single conversion by specifying an input and an output mime type.

Table 4: Sections of the service specific capabilities



Specification of the Format Conversion Service – Specification of Parameter Types

18/22

Name Data Type Description Multiplicity and Use

Input OA_MimeType The input format of the data

1 / mandatory

output OA_MimeType The output format of the data

1 / mandatory

isLossy Boolean

Since some conversions can degrade the quality of the given data, this operation indicates whether a conversion uses at least one lossy conversion adapter.

1 / mandatory

Table 5 Attributes of the service specific capabilities of section availableOrdinaryConversions



Specification of the Format Conversion Service –

19/22

8 Known Issues and Limitations

8.1.1 Support for streamed I/O

In the current specifications only files are considered. Maybe support is needed also for streamed inputand output. e.g. one company has a video in one format (consider a very large file) and wants to con-vert in another format for immediate display. Considering the current specifications, at the beginning thevideo has to be uploaded to your service, then converted (in its entirety), and then to be sent back. Thisprocedure can take a lot of time for huge file sizes. To improve the efficiency a streamed input and out-put may be considered. If streamed I/O is possible depends on the source- and target-format on theone hand and on the chosen target-platform.

8.1.2 Cooperation and Cascading between Service Instances

In the context of the Format Conversion Service the following question has raised.

Consider a service has multiple instances in an OSN. Instances of services can each have different ca-pabilities. In the case of the Format Conversion Service, each instance can support different conver-sions. The question is now, what the capabilities of each service are?

The capabilities supported by the current instance or the union of the capabilities of all instances?

The same question can be asked for the conversion itself.

In the first case another question raises. How does a user locate the correct service instance for histask? A possible solution could be to use a catalogue service to find an appropriate instance.

In the second case service instances would have to cooperate. The service instance of the service re-quest (getCapabilities, conversion) would figure out the correct service instance and delegate the re-quest to an appropriate instance without any involvement of the service requestor.

The service cooperation is not intended to make any catalogue service obsolete. This approach is

based on the assumption that a communication between two service instances can be very effectivesince they know their own structure very well and thus additional meta-information is not required todelegate any request.

Surely, there are more approaches to handle this scenario. In the following a few others will be drafted.

Precondition:

There are multiple service instances for a certain service.

Requirement:

The distribution of the service (multiple service instances) should be invisible to the service client.

Examples:

Services:• Format Conversion Service (FCS)

o What if the current service instance does not support the requested conversion but anotherinstance does?

• Document Access Service (DAS)o What if there are multiple DAS instances?

How to find a certain document? How to find the instance having a certain document?

Possible Solutions:1. A service client has to contact the proper service having the needed capability.

The problem of finding the correct instance is the service client’s problem.

Discussion:



Specification of the Format Conversion Service –

20/22

Of course, this in not really a solution! Every client would have to solve this problem if it occurs.There would be no reusability at all.

2. A service client always contacts a catalogue service to determine services offering the format-conversion in question.

Possible hits may be different Format Conversion Service instances and service-chains (possi-ble defined and annotated by the Service Chain Access Service).3. A service client may direct the request to any service instance.

A “broker” locates all registered services, checks their capabilities and chooses a proper in-stance.It delegates the service request to the found instance and redirects the result to the service re-questor.Such a broker would make use of Catalogue Services containing service-descriptions especiallyof Format Conversion Services and a Service Chain Access Service.



Specification of the Format Conversion Service – Appendix A: Abstract Test Suite (normative)

21/22

9 Appendix A: Abstract Test Suite (normative)

When creating an implementation specification of the Format Conversion Service, the “Rules for Im-

plementation Specifications of ORCHESTRA Services” defined in chapter 9.2.2.3 and the “Rules for theService Mapping to a given Platform” of the RM-OA shall be obeyed.

In addition, the following tests shall be performed to ensure conformance of an implementation specifi-cation to the platform-independent specification of the Format Conversion Service:

1. Syntactical Conformance

• Are all mandatory operations present?

• Are all mandatory parameters present?

• Are the operation signatures correct?

• Are there any new operations or parameters?

2. Semantical Conformance• Is the behaviour of the operation still the same?

Additional conformance checks that are specifically to the Format Conversion Service are not required.



Specification of the Format Conversion Service – Appendix B: UML Models (normative)

10 Appendix B: UML Models (normative)

10.1 XMI Model

The XMI Models of this interface specification can be downloaded from the OGC Portal under the fol-lowing URL:

https://portal.opengeospatial.org/index.php?m=projects&a=view&project_id=140&tab=2&artifact_id=22238

The XMI Model contains all parameters required by this service including those data types and excep-tions inherited or reused from other interface and service specifications.

Documents

Format Conversion Service Specification v1.7-EIG