Changes between Version 3 and Version 4 of Support Information Model 3 Assumed Types


Ignore:
Timestamp:
Sep 20, 2008, 6:19:13 AM (16 years ago)
Author:
KOBAYASHI, Shinji
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Support Information Model 3 Assumed Types

    v3 v4  
    2121 * Well-known object-oriented programming languages, including Java, C#, C++ and Eiffel.
    2222
    23 openEHRには二つの意図がある。第1には、モデルをベースとしたopenEHRのソフトウェアを保証するために、既存の実装技術を使ってできるだけ簡単に構築することである。第2には、便利に指定できるopenEHRモデルとして有効であるようにすると同時に、実装形式でみられる型について最小限想定しておくことである。ISO 11404 (2003)標準には実装技術のために「汎用データ型(GPD; General Purpose Datatypes[[FootNote(本仕様書には data types とあるが、ISO 11404のドキュメント内部にはDatatypesと表現されている。ここではISO 11404の表記を優先した)]])」の基本的セマンティクスが提示されており、本文書では型について想定されることについて記述するための基準となる基礎として利用している。本文書で記述される演算(operation)やプロパティ(property)は、ISO 11404で使われているものと互換性を持つが、11404がオブジェクト指向の関数を持たないためまったく同じではない。たとえば、概念的関数 has(!x:T) (集合の中に値が存在するかどうか試す)は以下で Set<T>型で定義されているが、ISO 11404 のSet型にはなく、その代わりに !IsIn(x: T; s: Set<T>)関数が定義されている。しかしながら、オブジェクト指向形式では、集合型で !IsIn関数が定義されていると通常は「そのsubsetである」ことを意味する。開発者のために明確な正確性を期するためにオブジェクト指向形式の関数やプロパティを本文書では仕様している。
     23openEHRには二つの意図がある。第1には、モデルをベースとしたopenEHRのソフトウェアを保証するために、既存の実装技術を使ってできるだけ簡単に構築することである。第2には、便利に指定できるopenEHRモデルとして有効であるようにすると同時に、実装形式でみられる型について最小限想定しておくことである。ISO 11404 (2003)標準には実装技術のために「汎用データ型(GPD; General Purpose Datatypes[[FootNote(本仕様書には data types とあるが、ISO 11404のドキュメント内部にはDatatypesと表現されている。ここではISO 11404の表記を優先した)]])」の基本的セマンティクスが提示されており、本文書では型について想定されることについて記述するための基準となる基礎として利用している。本文書で記述される演算(operation)やプロパティ(property)は、ISO 11404で使われているものと互換性を持つが、11404がオブジェクト指向の関数を持たないためまったく同じではない。たとえば、概念的関数 has(!x:T) (集合の中に値が存在するかどうか試す)は以下で Set<T>型で定義されているが、ISO 11404 のSet型にはなく、その代わりに !IsIn(x: T; s: Set<T>)関数が定義されている。しかしながら、オブジェクト指向形式では、集合型で !IsIn関数が定義されていると通常は「そのsubsetである」ことを意味する。開発者のために明確な正確性を期するためにオブジェクト指向形式の関数やプロパティを本文書では使用している。
    2424
    2525
    2626The intention in openEHR is twofold. Firstly, to ensure that openEHR software based on the models integrates as easily as possible with existing implementation technologies, and secondly, to make the minimum possible assumptions about types found in implementation formalisms, while making sufficient assumptions to both enable openEHR models to be conveniently specified. The ISO 11404 (2003) standard contains basic semantics of “general purpose data types” (GPDs) for information technology, and is used here as a normative basis for describing assumptions about types. The operations and properties described here are compatible with those used in ISO 11404, but not always the same, as 11404 does not use object-oriented functions. For example, the notional function has(!x:T) (test for presence of a value in a set) defined on the type Set<T> below is not defined on the ISO 11404 Set type; instead, the function !IsIn(x: T; s: Set<T>) is defined. However, in object-oriented formalisms, the function !IsIn defined on a Set type would usually mean ‘subset of’. In the interests of clarity for developers, an object-oriented style of functions and properties has been used here.
    2727
    28 !ISO8601:2004 is used as the definitional basis for assumed date/time types, since it is commonly used [file:///home/skoba/src/openehr-jp/adl/trunk/pdf2html/rm/support_im/support_im.htm#LinkTarget_16711 around the world, and is also the basis for the date/time types in W3C XML-schema. See section 3.4] [file:///home/skoba/src/openehr-jp/adl/trunk/pdf2html/rm/support_im/support_im.htm#LinkTarget_16711 on page 22]  below for details of dates and times.
     28!ISO8601:2004は想定される日時型の定義的な基礎として利用している。それは世界中で一般に広く利用されており、W3C XMLスキーマでもdate/time型の基礎として利用されている。詳細は3.4節を参照することとし、以下に日時についての詳細を示す
     29
     30!ISO8601:2004 is used as the definitional basis for assumed date/time types, since it is commonly used  around the world, and is also the basis for the date/time types in W3C XML-schema. See section 3.4 on page 22 below for details of dates and times.
     31
     32想定される型(assumed type)は二つのグループに識別される。プリミティブ型は
    2933
    3034Two groups of assumed types are identified: primitive types, which are those built in to a formalism’s type system, and library types, which are assumed to be available in a (class) library defined in the formalism. Thus, the type Boolean is always assumed to exist in a formalism, while the type Array<T> is assumed to be available in a library. For practical purposes, these two categories do not matter that much - whether String is really a library class (the usual case) or an inbuilt type doesn’t make much difference to the programmer. They are shown separately here mainly as an explanatory convenience.