INTERLIS 2.4 Referenzhandbuch

Ein Objekt (auch Objektinstanz oder einfach Instanz genannt) besteht aus den Daten eines Gegenstandes der realen Welt und ist eindeutig identifizierbar. Typischerweise besitzen zahlreiche Objekte gleichartige Eigenschaften und können daher zusammengefasst werden. Eine Menge von Objekten (Objektmenge) mit gleichartigen Eigenschaften wird als Klasse bezeichnet. Jeder Eigenschaft entspricht (mindestens) ein Attribut. INTERLIS 1 verwendete anstelle des Begriffs Klasse den Begriff Tabelle. Andere Begriffe für Klasse sind Entitätsmenge, Entitätstyp, Feature(typ).

Mit der Beschreibung einer Klasse wird unter anderem auch festgehalten, welche Eigenschaften oder Merkmale die einzelnen Objekte tragen. Diese werden Attribute genannt. Die Attributwerte der einzelnen Objekte sind dabei nicht beliebig, sondern müssen bestimmten Bedingungen genügen, die zur Beschreibung eines Attributes gehören.

INTERLIS bietet dafür eine Reihe von grundlegenden Datentypen an (Basis-Datentypen: Zeichenketten, numerische Datentypen, Aufzählungen, kartesische und elliptische 2D- bzw. 3D-Koordinaten, Linien, Flächen), auf deren Basis neue, komplexere Datenstrukturen definiert werden können. Um die Aussage noch zu präzisieren, können numerische Attribute mit einer Masseinheit versehen und auf ein Referenzsystem bezogen werden; Koordinaten können auf ein Koordinatensystem bezogen werden.

Datum und Zeit sind eigentlich Anwendungen von formatierten Wertebereichen. Weil Zeitangaben aber häufig vorkommen, wurde für Datum und Zeit eine eigene Struktur definiert (XMLTime, XMLDate und XMLDateTime).

Neben diesen Basis-Datentypen kann ein Attribut auch Unterstrukturen enthalten. Die einzelnen Elemente der Unterstruktur sind als Strukturelemente aufzufassen, die nur im Zusammenhang mit ihrem Hauptobjekt existieren und auch nur über dieses auffindbar sind. Der Aufbau der Strukturelemente wird ähnlich wie jener von Klassen beschrieben.

Abgesehen davon, dass alle Attributwerte ihrem jeweiligen Typ entsprechen müssen, können weitere Bedingungen formuliert werden. INTERLIS unterscheidet zwischen folgenden Arten von Konsistenzbedingungen:

Klassen sind entweder eigenständig oder erweitern (spezialisieren, erben) eine Basisklasse. D.h. die Beschreibung einer Klasse ist entweder unabhängig oder enthält Erweiterungen von einer anderen, ererbten Beschreibung. Eine Klassenerweiterung (auch Unterklasse oder Subklasse genannt) kann einerseits zusätzliche Attribute und Konsistenzbedingungen haben, andererseits übernommene Bedingungen (Datentypen, Konsistenzbedingungen) verschärfen.

Jedes einzelne Objekt gehört zu genau einer Klasse (man sagt auch: ist Objektinstanz oder Instanz einer Klasse). Es erfüllt aber immer auch sämtliche Bedingungen, welche die Basisklassen (d.h. die Oberklassen) stellen. Zu jeder Klasse gibt es eine Menge von Objekten, die Instanzen der Klasse oder einer ihrer Erweiterungen sind. Im Falle konkreter Klassen besteht eine normalerweise kleinere Untermenge von Instanzen, die exakt zu dieser Klasse gehören.

Die Elemente von Unterstrukturen sind keine eigentlichen selbständigen Objekte, sondern Strukturelemente und gehören damit auch nicht zur Menge der Instanzen irgendeiner Klasse.

Koordinaten- und Referenzsysteme sowie Grafiksignaturen stellen sich aus der Sicht der Anwendung als Modellelement (bzw. Schemaelement) dar, die in den Anwendungsdefinitionen verwendet werden können. Da aber verschiedene Koordinaten- und Referenzsysteme und vor allem verschiedene Grafiksignaturen auf die gleiche Art beschrieben werden können, macht es Sinn, ihre Eigenschaften ebenfalls innerhalb von Modellen mittels Klassen zu beschreiben. Jedem einzelnen System, bzw. jeder Grafiksignatur (z.B. ein Punktsymbol, eine Linienart) entspricht dann ein Objekt.

Meta-Objekte müssen in einem Meta-Modell definiert sein (s. Kapitel 3.10.1, “Allgemeine Aussagen zu Metaobjekten”). Die verwendbaren Objekte müssen explizit als Meta-Objekte gekennzeichnet sein (Erweiterungen der vordefinierten Klasse METAOBJECT) und können dann von der Anwendung über den Namen referenziert werden. Dafür ist es nötig, dass die Meta-Objekte dem Werkzeug, das die Anwendungsdefinition verarbeitet, mittels Behältern (vgl. Kapitel 2.4.5, “Behälter, Replikation und Datentransfer”) zur Verfügung stehen.

INTERLIS 2 unterscheidet (im Gegensatz zu INTERLIS 1) zwei Arten von Beziehungen zwischen Objekten: eigentliche Beziehung und Referenzattribut.

Als eigentliche Beziehung wird eine Menge von Objektpaaren (bzw. im allgemeinen Fall von Objekt-n-Tupeln) bezeichnet. Das erste Objekt jedes Paares gehört zu einer ersten Klasse A, das zweite zu einer zweiten Klasse B. Dabei soll die Zuordnung von Objekten zu den Paaren vorgegeben sein, sie muss also nur beschrieben, d.h. modelliert werden. Wie weiter unten im Kapitel 2.5, “Sichten-Konzept” gezeigt wird, ist es im Gegensatz dazu auch möglich, Zuordnungen algorithmisch z.B. aufgrund von Attributwerten zu berechnen.

Eigentliche Beziehungen werden als eigenständige Konstrukte, so genannte Beziehungsklassen (bzw. Assoziationsklassen), beschrieben, die auch selbst wieder erweiterbar sind. INTERLIS 2 unterstützt nicht nur Zweierbeziehungen, sondern erlaubt auch mehrfache Beziehungen und solche mit eigenen Attributen. Eine Beziehungsklasse ist damit auch selbst wieder eine Objektklasse.

Wichtige Eigenschaften solcher Beziehungen sind:

Mit einem Referenzattribut wird der Bezug von einem Objekt bzw. einem Strukturelement zu einem anderen Objekt geschaffen. Eine solche Beziehung ist nur dem referenzierenden, nicht aber dem referenzierten Objekt bekannt. Sie ist also einseitig.

Ohne die Unabhängigkeit der Themen zu verletzen, können mittels spezieller Kennzeichnung (EXTERNAL) auch Beziehungen (d.h. eigentliche Beziehungen und Referenzattribute) definiert werden, die einen Bezug zu Objekten eines anderen Behälters des gleichen oder eines anderen Themas schaffen. Voraussetzung dazu ist allerdings, dass die Struktur, in der die Beziehung definiert wird, zu einem Thema gehört, das von demjenigen, zu dessen Klasse es verweist, abhängig ist.

Im Interesse einer klaren Ordnung können sich Beziehungen nur auf Klassen beziehen, die an der Stelle wo die Beziehungsklasse (bzw. das Referenzattribut) definiert wird, bereits bekannt sind.

Als Behälter wird eine abgeschlossene Sammlung von Objekten bezeichnet, die zu einem Thema oder zu dessen Erweiterungen gehören. Abgeschlossen heisst, dass ein Behälter alle Objekte enthalten soll, die innerhalb des Themas zueinander in Beziehung stehen. Typischerweise wird ein Behälter alle Objekte einer bestimmten Gegend (z.B. einer Gemeinde, eines Kantons oder gar des ganzen Landes) enthalten. Ein Behälter kann insbesondere auch Daten verschiedener Erweiterungen (z.B. verschiedener Kantone mit eigenen Themenerweiterungen) enthalten. Dies bedingt allerdings, dass im Rahmen einer solchen Transfergemeinschaft, die Bezeichnungen der Modelle, Themen und Themenerweiterungen eindeutig sind.

Im Rahmen von Konsistenzbedingungen wird häufig von «allen» Objekten einer Klasse gesprochen. Konzeptionell meint man damit auch grundsätzlich alle Objekte, die die gewünschte Eigenschaft haben und die es überhaupt, d.h. behälterübergreifend gibt. Es ist aber aus verschiedenen Gründen (Effizienz, Verfügbarkeit, Zugriffsberechtigung, etc.) offensichtlich, dass eine Überprüfung nur innerhalb der lokal zugänglichen Behälter möglich ist. Im Falle von Behältern mit Meta-Objekten gelten die Konsistenzbedingungen ausdrücklich nur innerhalb eines Behälters, da davon ausgegangen wird, dass die Meta-Daten beschreibenden Charakter haben und deshalb jeweils vollständig (quasi als Bibliothek) in einem Behälter zur Verfügung stehen müssen.

Es werden verschiedene Arten von Behältern unterschieden:

INTERLIS regelt nicht, wie die Objekte in den Systemen gehalten werden müssen. Die Regelungen betreffen nur die Schnittstelle zwischen den Systemen. Aktuell ist eine Schnittstelle zum Transfer von Behältern als XML-Dateien definiert. Dabei wird nicht nur der vollständige Transfer des ganzen Behälters, sondern auch die inkrementelle Nachlieferung unterstützt.

Beim vollständigen Transfer wird davon ausgegangen, dass der Empfänger neue, eigenständige Objektkopien aufbaut, die keinen unmittelbaren Zusammenhang zum Ursprungsobjekt aufweisen. Im Rahmen des vollständigen Transfers müssen die Objekte darum nur mit einer temporären Transferidentifikation (Transferidentifikator, abgekürzt TID) versehen werden. Diese wird zum Transferieren von Beziehungen genutzt.

Beim inkrementellen Transfer wird davon ausgegangen, dass der Sender einmal einen Initialzustand eines Datenbehälters (andere Behälterarten sind ausgeschlossen) liefert und den Empfänger anschliessend mit Nachlieferungen versorgt, die diesem erlauben, seine Daten zu aktualisieren (siehe Abbildung 4). Die Objekte werden damit repliziert und behalten den Zusammenhang zum Originalobjekt, d.h. sie können nicht unabhängig vom Original verändert werden und erhalten keine neue Identifikation.

Dabei geht man davon aus, dass zwischen den Betreibern der Primär- und der Sekundär-Datenbanken vertragliche Abmachungen getroffen werden (unter anderem Umfang, Häufigkeit der Nachlieferung), die aktuell nicht mit Instrumenten von INTERLIS beschrieben werden können. Für die eigentliche Nachlieferung stellt INTERLIS aber die nötigen Mittel zur Verfügung. Neue Objekte werden wie beim ersten Transfer mitgeteilt. Ihnen ist eine eindeutige Objektidentifikation (Objektidentifikator, abgekürzt OID) zugeordnet, die über die Zeit erhalten bleiben muss. Bei Änderungen wird auf diesen eindeutigen OID Bezug genommen und alle Attribute des Objektes (inkl. aller Strukturelemente von Strukturattributen) werden neu geliefert. Auf die gleiche Art werden auch Löschungen mitgeteilt. Dabei trägt primär der Sender die Verantwortung für die Konsistenz der Objekte (z.B. Einhaltung von Konsistenzbedingungen, Korrektheit und Kardinalität von Beziehungen). Er meldet dazu den Empfängern, welche Objekte geändert oder gelöscht und welche neu erzeugt wurden. Bei themenübergreifenden Referenzattributen wird – im Interesse der Unabhängigkeit der Themen – nicht vorausgesetzt, dass die Integrität jederzeit gewährleistet ist. Es ist Sache des Empfängers, damit zurechtzukommen, dass vorübergehend Inkonsistenzen zwischen Basisthemen und abhängigen Themen bestehen, d.h. dass ein referenziertes Objekt nicht existiert.

Der Rahmen, in dem die Eindeutigkeit des OID gewährleistet ist, ist durch INTERLIS selbst nicht bestimmt. Eine Möglichkeit, wie ein solcher OID aufgebaut sein kann, ist in Anhang F Aufbau von Objektidentifikatoren (OID) beschrieben. Andere Möglichkeiten sind aber ohne weiteres denkbar. Wichtig ist, dass der OID durch die verschiedenen Datenerfasser einer Transfergemeinschaft bei korrekter Anwendung der Regel zum Aufbau des OID immer im Rahmen der Transfergemeinschaft eindeutig ist. Je nach Aufbau des OID ist der inkrementelle Datenaustausch in einem grösseren (z.B. weltweit) oder in einem kleineren (z.B. organisationsintern) Rahmen möglich. Das gewählte Verfahren zur Bestimmung des OID definiert somit die potenzielle Transfergemeinschaft.

Ein Objekt darf nur in seinem Originalbehälter bzw. ausserhalb nur mit Erlaubnis dessen Verwalters verändert werden. Alle anderen, sekundären Behälter dürfen ein Objekt nur als Folge einer Nachlieferung verändern. INTERLIS 2 verlangt darum, dass – im Rahmen der inkrementellen Nachlieferung – nebst den Objekten auch die Behälter eindeutig und dauerhaft identifizierbar sein müssen. Die Behälter erhalten dann ebenfalls einen OID. Beim vollständigen Transfer braucht auch der Behälter nur eine Transferidentifikation (TID). Wo die Unterscheidung zum normalen OID (bzw. TID) wesentlich ist, wird vom Behälteridentifikator BOID (bzw. vom Behältertransferidentifikator BID) gesprochen.

Es muss davon ausgegangen werden, dass verschiedene Objekte zunächst in Behältern z.B. einer Gemeinde geführt werden, diese Behälter dann als Ganzes an den Kanton übermittelt und dort in Behälter, die pro Thema den ganzen Kanton enthalten, integriert werden. Allenfalls werden diese Behälter dann wieder z.B. an den Bund weitergegeben. Damit jederzeit klar ist, welches der Originalbehälter ist, wird dessen BOID bei jedem replizierten Objekt mitgegeben. Ein Empfänger kann damit eine Behälter-Verwaltung aufbauen, in dem er festhält, in welchen eigenen Behältern er replizierte Objekte von welchen Originalbehältern aufbewahrt (INTERLIS 2 bietet auch die nötigen Mittel an, dass solche Behälter mit INTERLIS selbst beschrieben und wie normale Objekte ausgetauscht werden können). Nutzt der Empfänger die Eigenschaft von INTERLIS 2, dass bei themenübergreifenden Beziehungen nicht nur die OID des Bezugsobjektes sondern auch die BOID dessen Originalbehälters transferiert wird, kann er auf effiziente Art bestimmen, in welchem seiner Behälter das Bezugsobjekt liegt.

Die eigentliche Sprache verwendet nur die druckbaren US-ASCII-Zeichen (32 bis 126). Welche Zeichen nebst dem Leerzeichen als Zwischenräume gelten, ist durch die konkrete Compiler-Implementation festzulegen. Diese legt auch fest, welche Zeichen oder Zeichenkombinationen als Zeilenende gelten. Wie die Zeichen gespeichert werden (Zeichensatz) ist Sache der Implementation des Compilers. Sie kann insbesondere je nach Plattform unterschiedlich sein.

Im Rahmen von Kommentaren dürfen auch weitere Zeichen (z.B. Umlaute und Akzente) vorkommen.

Ein Name ist definiert als eine Folge von maximal 255 Buchstaben, Ziffern und Unterstrichen, wobei das erste Zeichen ein Buchstabe sein muss. Gross- und Kleinbuchstaben werden dabei unterschieden. Namen, die mit reservierten Wörtern der Sprache (vgl. Kapitel 3.2.7, “Sonderzeichen und reservierte Wörter”) zusammenfallen, sind unzulässig.

Näheres zur Eindeutigkeit und zum Gültigkeitsbereich von Namen ist im Kapitel 3.5.4, “Namensräume” beschrieben.

Zeichenketten (Strings) kommen im Zusammenhang mit Konstanten vor. Sie beginnen und enden mit einem Anführungszeichen und dürfen sich nicht über mehrere Zeilen erstrecken. \" steht für ein Anführungszeichen und \\ für einen «Backslash» innerhalb des Strings.

Eine Sequenz von \u, unmittelbar gefolgt von exakt vier Hexadezimalziffern, steht für ein beliebiges Unicode-Zeichen. Zeichen ab U+10000 sind wie in der UTF-16-Codierung mit zwei Surrogatcodes zu bezeichnen (siehe https://www.unicode.org).

Zahlen kommen in verschiedener Weise vor: Positive ganze Zahlen inklusive 0 (PosNumber), ganze Zahlen (Number), Dezimalzahlen (Dec) und strukturierte Zahlen. Bei Dezimalzahlen kann die Skalierung als Zehnerpotenz angegeben werden (z.B. 1E2 ist 100, 1E-1 ist 0.1). Strukturierte Zahlen machen nur im Zusammenhang mit entsprechenden Einheiten und Wertebereichen (z.B. Uhrzeit) einen Sinn. Wesentlich ist der Wert der Zahl, nicht deren Darstellung. So ist etwa 007 dieselbe Zahl wie 7.

Für verschiedene Zwecke müssen einem Beschreibungsgegenstand Eigenschaften zugeordnet werden. Dies kann mit einer generellen Syntax erfolgen:

Um zu definieren, dass an einer bestimmten Stelle einer Syntaxregel solche Eigenschaften definiert werden sollen, wird in der Syntax folgendes Konstrukt eingefügt:

Man schreibt also "Properties" und definiert in spitzen Klammern die zulässigen Schlüsselwörter. Nimmt man als Beispiel die Regel ClassDef (vgl. Kapitel 3.5.3, “Klassen und Strukturen”) werden mit "Properties<ABSTRACT,EXTENDED,FINAL>" die Schlüsselwörter "ABSTRACT", "EXTENDED" und "FINAL" für die Beschreibung von Eigenschaften akzeptiert. In einer INTERLIS 2-Definition wären dann unter anderem folgende Definitionen möglich:

Erläuterungen werden dort verlangt, wo ein Sachverhalt näher beschrieben werden muss. Aus der Sicht des Standard-Mechanismus wird die Erläuterung nicht weiter interpretiert, also als Kommentar aufgefasst. Es ist aber durchaus zulässig, Erläuterungen detaillierter zu formalisieren und damit einer weitergehenden maschinellen Verarbeitung zugänglich zu machen. Als Anfang und Abschluss einer Erläuterung wurde // gewählt. Innerhalb der Erläuterung dürfen zwei aufeinander folgende Schrägstriche nie vorkommen.

Sonderzeichen und reservierte Wörter sind in den Syntaxregeln der Sprache (nicht aber bei einer Datenbeschreibung) immer zwischen Apostrophen geschrieben, z.B. ',' oder 'MODEL'. Die reservierten Wörter werden grundsätzlich mit Grossbuchstaben geschrieben. Konflikte zwischen Namen und reservierten Wörtern sind vermeidbar, wenn Namen nicht ausschliesslich aus Grossbuchstaben bestehen. Es werden folgende reservierten Wörter verwendet (einige davon wurden in INTERLIS 1 bzw. 2.3 benutzt und bleiben aus Gründen der Kompatibilität reserviert; sie sind nicht fett und kursiv dargestellt):

Es werden zwei Kommentarformen angeboten:

Als Modell wird eine in sich geschlossene, vollständige Definition bezeichnet. Je nach Art des Modells kann es verschiedene Konstrukte enthalten.

Ein reines Typenmodell (TYPE MODEL) darf nur Masseinheiten, Wertebereiche, Funktionen und Linienformen deklarieren.

Ein Referenzsystem-Modell (REFSYSTEM MODEL) soll nebst den Definitionen eines Typenmodells nur Themen und Klassen deklarieren, die im Bezug zu Erweiterungen der vordefinierten Klassen AXIS bzw. REFSYSTEM stehen (vgl. Kapitel 3.10.3, “Referenzsysteme”). Die Einhaltung dieser Regel kann durch die Sprache nicht erzwungen werden. Es ist Sache des Anwenders, sich daran zu halten.

Ein Signaturenmodell (SYMBOLOGY MODEL) soll nebst den Definitionen eines Typenmodells nur Themen und Klassen, die im Bezug zu Erweiterungen der vordefinierten Klasse SIGN stehen, sowie Laufzeitparameter deklarieren (vgl. Kapitel 3.16, “Darstellungsbeschreibungen” und Kapitel 3.11, “Laufzeitparameter”). Die Einhaltung dieser Regel ist ebenfalls Sache des Anwenders.

Wird keine solche einschränkende Modelleigenschaft definiert, darf ein Modell alle möglichen Konstrukte enthalten.

Nach dem Modellnamen kann optional die Sprache angegeben werden. Wenn möglich sollte die Angabe anhand der durch die ISO-Norm 639 standardisierten zwei-buchstabigen Bezeichnungen in Kleinbuchstaben erfolgen (siehe https://www.iso.org); zum Beispiel steht "de" für Deutsch, "fr" für Französisch, "it" für Italienisch, "rm" für Rätoromanisch und "en" für Englisch. Durch einen Unterstrich getrennt darf ein Ländercode gemäss ISO-Norm 3166 nachgestellt werden, um die in einem bestimmten Land benutzte Varietät einer Sprache zu bezeichnen: "de_CH" steht für das in der Schweiz verwendete (Schrift-)Deutsch. Diese Angabe hat dokumentarischen Wert. Sie steht im Zusammenhang mit der Möglichkeit, ein Modell als eine Übersetzung eines anderen zu deklarieren (TRANSLATION OF). Die beiden Modelle müssen dann strukturell exakt übereinstimmen. Sie dürfen sich also nur in den verwendeten Namen unterscheiden. Die Deklaration als Übersetzung ist aber nicht an die Sprachangabe gebunden. Um z.B. lokale oder branchenspezifische Sprachgebräuche zu unterstützen, sind insbesondere auch Übersetzungen in die gleiche Sprache wie die Ursprungsbeschreibung zulässig.

Mit der Angabe NOINCREMENTALTRANSFER wird definiert, dass beim Datentransfer (vgl. Kapitel 4, “Sequentieller Transfer”) kein inkrementeller Transfer unterstützt werden muss.^[1] Insbesondere enthält das aus dem Modell generierte XML-Schema keine entsprechenden Möglichkeiten.

Anschliessend wird mittels Angabe des entsprechenden URI (vgl. Kapitel 3.2.3, “Zeichenketten”) der Herausgeber des Modells identifiziert. Es wird erwartet, dass der Modellname in diesem Kontext eindeutig ist.

Mit der Modellversion können verschiedene Versionen (insbesondere verschiedene Entwicklungsstufen) eines Modells unterschieden werden. In der Erläuterung können zusätzliche Angaben wie Hinweise zur Kompatibilität mit früheren Versionen gemacht werden. In einem bestimmten Zeitpunkt soll aber nur eine Modellversion bestehen. Deshalb wird beim Import von Modellen auch keine Version angegeben. Ist ein Modell eine Übersetzung eines anderen, ist dessen Version in eckigen Klammern anzugeben. Mit der Versionsangabe im Rahmen einer Übersetzungsdefinition (TRANSLATION OF) wird nur dokumentiert, auf Grund welcher Basisversion die Übersetzung erstellt wurde und mit welcher sie also auch strukturell exakt übereinstimmt.

Das Schlüsselwort CONTRACTED hat keine Funktion mehr, bleibt zur Kompatibilität hier aber zulässig.

Optional kann - eingeleitet durch das Schlüsselwort CHARSET - der Name eines Zeichensatzes definiert werden. Zulässige Namen werden durch IANA festgelegt.^[2] Fehlt die Angabe, gilt der Zeichensatz gemäss Anhang D. Die Definition des Zeichensatzes definiert den Umfang an Zeichen die eine Software verarbeiten (wie z.B. Speichern, Suchen, Sortieren, Ausdrucken) können muss und nicht den im Transfer zulässigen Zeichensatz oder die zulässige Zeichencodierung (vgl. Kapitel 4.3.2, “Zeichencodierung”).

Mit der Angabe nach XMLNS kann optional für den XML-Transfer gemäss Kapitel 3 der XML-Namensraum^[3] festgelegt werden.^[4] Ohne Angabe ergibt sich der XML-Namensraum nach einer fixen Regel (vgl. Kapitel 4, “Sequentieller Transfer”) aus dem Namen des Modells.

Bezieht sich ein INTERLIS-Konstrukt auf eine Definition, die in einem anderen Modell vorgenommen wurde, muss dieses Modell importiert werden (Schlüsselwort IMPORTS). So können beispielsweise Themen erweitert und der Bezug auf Klassen geschaffen werden. IMPORTS eröffnet aber nur die Möglichkeit des Gebrauchs. Bei der Verwendung der importierten Definitionen, sind diese dennoch mit qualifiziertem Namen (Modell, Thema) zu referenzieren, ausser man verwendet das Schlüsselwort UNQUALIFIED. Themen gehören nur dann zu einem Modell (und können entsprechend Kapitel 4.3.6, “Codierung von Themen” transferiert werden), wenn sie innerhalb dieses Modells definiert sind (Regel TopicDef).

Mit der Sprache verbunden ist auch ein vordefiniertes Basis-Modell "INTERLIS" (vgl. Anhang A Das interne INTERLIS-Datenmodell). Dieses muss nicht importiert werden. Hingegen stehen auch dessen Elemente nur dann mit unqualifizierten Namen zur Verfügung, wenn das Modell mit IMPORTS UNQUALIFIED INTERLIS eingeführt wird.

Ein Thema (Schlüsselwort TOPIC) enthält alle zur Beschreibung eines bestimmten sachlichen Teils der Realwelt nötigen Definitionen. Ein Thema kann auch Typen wie Masseinheiten, Wertebereiche oder Strukturen definieren oder diese vom umhüllenden Modell oder einem importierten Modell benützen. In runden Klammern können die Vererbungseigenschaften definiert werden. Enthält ein Thema abstrakte Definitionen, die nicht im selben Thema konkretisiert werden, muss das Thema als ABSTRACT deklariert werden. Abstrakte Definitionen müssen dann in konkreten Erweiterungen des Themas noch konkretisiert werden. Für einen Datentransfer braucht es ein konkretes Thema. Da sich eine Erweiterung eines Themas immer auf ein Thema mit einem anderen Namen bezieht, macht EXTENDED keinen Sinn und ist deshalb nicht zulässig.

Zu einem bestimmten Thema, das konkrete Klassen enthält, können beliebig viele Behälter (Datenbanken etc.) existieren. Sie weisen alle die dem Thema entsprechende Struktur auf, enthalten aber unterschiedliche Objekte.

In einem Datenbehälter kommen dabei nur die Instanzen von Klassen (und ihrer Unterstrukturen) vor. Enthält ein Thema Darstellungsbeschreibungen, können drei Arten von Behältern gebildet werden:

Datenbehälter und Objekte weisen in der Regel eine Objektidentifikation auf. Ihr Wertebereich ergibt sich aus der entsprechenden Definition: BASKET OID AS für die Objektidentifikationen der Datenbehälter, OID AS für die Objektidentifikationen der Objekte, sofern bei der jeweiligen Klasse keine spezifische Definition dafür gemacht wird. Wurde einem Thema ein OID-Wertebereich zugeordnet, kann die Zuordnung in Erweiterungen nicht mehr geändert werden. In vielen Fällen wird es Sinn machen, den Standardwertebereich STANDARDOID (vgl. Kapitel 3.8.9, “Wertebereiche von Objektidentifikationen” sowie Anhänge A und F) zu verwenden. Fehlt die OID-Definition für ein Thema oder eine bestimmte Klasse, erhalten diese Behälter bzw. Objekte keine stabilen Objektidentifikationen. Der inkrementelle Datenaustausch ist dann für sie nicht möglich.

Ohne weitere Angaben ist ein Thema datenmässig unabhängig von anderen Themen. Datenmässige Abhängigkeiten entstehen als Folge von Beziehungen bzw. Referenzattributen, die in einen anderen Behälter verweisen, durch spezielle Konsistenzbedingungen oder durch den Aufbau von Sichten oder Grafikdefinitionen auf Klassen oder anderen Sichten, nicht aber durch die Verwendung von Metaobjekten (vgl. Kapitel 3.10.1, “Allgemeine Aussagen zu Metaobjekten”). Im Interesse der klaren Erkennbarkeit solcher Abhängigkeiten, müssen diese aber bereits im Themenkopf explizit deklariert werden (Schlüsselwort DEPENDS ON). Die detaillierten Definitionen (z.B. Beziehungsdefinitionen) dürfen dann die Abhängigkeitsdeklaration nicht verletzen. Zyklische Abhängigkeiten sind nicht erlaubt. Ein erweitertes Thema besitzt ohne zusätzliche Deklarationen dieselben Abhängigkeiten wie sein Basis-Thema.

Referenziert ein Thema direkt oder indirekt generische Festlegungen, die letztlich erst im Transfer festgelegt werden, müssen sie explizit aufgeführt werden (DEFERRED GENERICS). Aktuell besteht diese Möglichkeit nur für Koordinaten-Wertebereiche (vgl. Kapitel 3.8.8, “Koordinaten”).

Eine Klassendefinition (Schlüsselwort CLASS) deklariert die Eigenschaften aller zugehörigen Objekte. Eine Klasse wird in einem Thema abschliessend definiert. Klassendefinitionen sind erweiterbar, wobei eine Erweiterung primär sämtliche Attribute ihrer Basis-Klasse erbt. Deren Wertebereiche dürfen eingeschränkt werden. Zudem dürfen weitere Attribute oder zusätzliche Konsistenzbedingungen definiert werden.

Der Wertebereich der Objektidentifikationen aller Objekte dieser Klasse kann explizit festgelegt werden (OID AS oder NO OID). Fehlt die Definition, gilt diejenige des Themas, es sei denn, es werde explizit festgelegt, dass keine Objektidentifikationen gefragt sind (NO OID). Fehlt die Definition auch beim Thema, gilt implizit NO OID. NO OID bedeutet, dass die Objektidentifikation nicht stabil ist. Als Folge ist es weder möglich, Objekte dieser Klasse inkrementell nachzuliefern, noch Referenzen (Beziehungen, Beziehungsattribute) auf diese Klasse zu definieren. Eine bereits gemachte OID-Definition kann nicht erweitert werden, ausser dass ein geerbtes NO OID durch ANY, und ein geerbtes ANY durch eine konkrete Definition ersetzt werden kann. Ein geerbtes ANY kann jedoch nicht durch NO OID ersetzt werden. (vgl. Kapitel 3.8.9, “Wertebereiche von Objektidentifikationen”).

Als Teil einer Klassendefinition können Konsistenzbedingungen angegeben werden. Die Bedingungen stellen Regeln dar, welchen die Objekte zusätzlich genügen müssen. Ererbte Konsistenzbedingungen können nicht ausser Kraft gesetzt werden, sondern gelten immer zusätzlich zu den lokal deklarierten.

Die Objekte einer Klasse sind immer selbständig und individuell identifizierbar. Strukturen (Schlüsselwort STRUCTURE) sind zwar formal gleich wie Klassen definiert, ihre Strukturelemente sind jedoch unselbständig und können nicht einzeln identifiziert werden. Sie kommen entweder innerhalb von Unterstrukturen von Objekten vor (vgl. Kapitel 3.6, “Attribute”), oder sie existieren nur temporär als Ergebnisse von Funktionen. Strukturen dürfen zu Klassen erweitert werden; Objekte solcher Klassen sind wie normale Objekte selbständig und identifizierbar. Klassen dürfen nicht zu Strukturen erweitert werden.

Spezielle Klassen wie diejenigen für Referenzsysteme, Koordinatensystem-Achsen und Grafik-Signaturen (also Erweiterungen der vordefinierten Klasse METAOBJECT) werden im Kapitel 3.10, “Umgang mit Metaobjekten” beschrieben.

In runden Klammern (Regel Properties) können die Vererbungseigenschaften definiert werden. Es sind alle Möglichkeiten zulässig. Enthält eine Klasse oder Struktur abstrakte Attribute, ist sie als ABSTRACT zu deklarieren. Abstrakte Attribute müssen dann in konkreten Erweiterungen der Klasse noch konkretisiert werden. Es ist aber auch zulässig, Klassen als abstrakt zu erklären, deren Attribute vollständig definiert sind. Objektinstanzen können nur für konkrete Klassen existieren, die innerhalb eines Themas definiert wurden, d.h. für einen Datentransfer braucht es konkrete Klassen, die in einem konkreten Thema definiert sind.

Wird eine einzelne Klasse und nicht ein ganzes Thema geerbt, dürfen keine Beziehungen (vgl. Kapitel 3.7, “Eigentliche Beziehungen”) zu ihr definiert sein.

Erweitert ein Thema ein anderes, werden alle Klassen des geerbten Themas übernommen. Sie werden also zu Klassen des aktuellen Themas und haben denselben Namen wie im geerbten Thema. Eine solche Klasse kann auch unter Beibehaltung ihres Namens erweitert werden (EXTENDED). Erweitert z.B. ein Thema T2 das Thema T1, das die Klasse C enthält, gibt es mit C (EXTENDED) innerhalb von T2 nur eine Klasse, nämlich C. Neue Klassen, die sich namensmässig von den geerbten unterscheiden müssen, dürfen auch geerbte erweitern. Mit C2 EXTENDS C, gibt es dann in T2 zwei Klassen (C und C2). Da INTERLIS im Interesse von Einfachheit und Klarheit nur Einfachvererbung unterstützt, ist EXTENDED allerdings nur zulässig, wenn weder im Basis-Thema noch im aktuellen Thema die Basis-Klasse mit EXTENDS erweitert wurde. EXTENDED und EXTENDS schliessen sich in der gleichen Klassendefinition aus.

Welche Namen qualifiziert werden müssen (durch Model-Name bzw. durch Model-Name.Topic-Name) ist am Schluss des folgenden Abschnitts (vgl. Kapitel 3.5.4, “Namensräume”) erklärt. Klassen und Strukturen, die nicht auf einer bereits definierten Klasse oder Struktur aufbauen, brauchen keinen EXTENDS-Teil.

Als Namensraum bezeichnet man eine Menge von (eindeutigen) Namen. Jedes Modellierungselement (Datenmodell, Thema, Klassenelement) sowie die Metadaten-Behälter stellen jeweils einen eigenen Namensraum für ihre Namenskategorien (Typnamen, Bestandteilnamen, Metaobjektnamen) bereit.

Modellierungselemente gibt es auf drei Hierarchiestufen:

Metadaten-Behälter-Namen eröffnen den Zugang zu den Metaobjekten (vgl. Kapitel 3.10, “Umgang mit Metaobjekten”).

Es gibt drei Namenskategorien, die folgende Namen enthalten:

Erweitert ein Modellierungselement ein anderes, werden seinen Namensräumen alle Namen des Basis-Modellierungselementes zugefügt. Um Missverständnisse auszuschliessen übernehmen Modellierungselemente zudem die Namen des übergeordneten Modellierungselementes entsprechend der Namenskategorie. Ein lokal im Modellierungselement definierter Name darf nicht mit einem übernommenen Namen kollidieren, es sei denn es handle sich ausdrücklich um eine Erweiterung (EXTENDED).

Will man Beschreibungselemente des Datenmodells referenzieren, muss ihr Name normalerweise qualifiziert, d.h. mit vorangestelltem Modell- und Thema-Namen angegeben werden. Unqualifiziert können die Namen der Namensräume des jeweiligen Modellierungselementes verwendet werden.

Jedes Attribut wird durch seinen Namen und seinen Typ definiert. In runden Klammern (Regel Properties) können die Vererbungseigenschaften definiert werden. Ist ein Attribut eine Erweiterung eines geerbten Attributes, muss dies mit EXTENDED ausdrücklich angemerkt werden. Ist der Wertebereich eines Attributs abstrakt, muss das Attribut als ABSTRACT deklariert werden. Ein numerisches Attribut (vgl. Kapitel 3.8.5, “Numerische Datentypen”) kann als eine Unterteilung (Schlüsselwort SUBDIVISION) des ebenfalls numerischen Vorgängerattributes definiert sein (z.B. Minuten als Unterteilung von Stunden). Dieses Vorgängerattribut muss ganzzahlig und der Wertebereich der Unterteilung muss positiv sein. Ist die Unterteilung kontinuierlich (Schlüsselwort CONTINUOUS), muss die Differenz der Wertebereichsgrenzen mit dem Faktor zwischen der Einheit des Attributs und demjenigen des Vorgängerattributs übereinstimmen. Ist zu einer Unterteilung ein Referenzsystem definiert, muss dieses zum Wertesystem eines direkten oder indirekten Vorgängerattributes passen. Ein INTERLIS-Compiler oder ein Laufzeitsystem muss dies jedoch nicht überprüfen.

Wird der Attributwert mittels eines Faktors (vgl. Kapitel 3.13, “Ausdrücke”) festgelegt, muss dessen Ergebnistyp zuweisungskompatibel zum definierten Attribut sein, d.h. es muss den gleichen Wertebereich oder einen erweiterten, d.h. spezialisierten Wertebereich aufweisen. Im Rahmen von Sichten - vor allem bei Vereinigungen und Sichterweiterungen (vgl. Kapitel 3.15, “Sichten”) – können mehrere Faktoren festgelegt werden und in zusätzlichen Sichterweiterungen noch zusätzliche beigefügt werden. Es gilt jeweils der letzte (Basis zuerst, Erweiterung anschliessend), dessen Wert definiert ist. Mittels eines Faktors festgelegte Attribute sollen, falls sie nur innerhalb weiterer Faktoren von Bedeutung sind, vom Datentransfer ausgeschlossen werden können, sie sollen dann als transient bezeichnet werden.

Ein Attribut kann in Erweiterungen wie folgt übersteuert werden:

Im Rahmen von Erweiterungen ist es zulässig, nur MANDATORY anzugeben. Es gilt dann der bereits definierte Attributtyp. Es wird aber verlangt, dass der Wert immer definiert ist.

Als Typ eines Attributs kommen direkte Typendefinitionen (Regel Type) und die Verwendung bereits definierter Wertebereiche (Regel DomainRef) in Frage. Die verschiedenen Möglichkeiten sind im Kapitel 3.8, “Wertebereiche und Konstanten” aufgeführt.

Mit einem Referenzattribut kann der Verweis zu einem anderen Objekt geschaffen werden. Zusammenhänge zwischen eigenständigen Objekten sind mittels eigentlichen Beziehungen (vgl. Kapitel 3.7, “Eigentliche Beziehungen”) zu definieren.

Die Klassen, deren Objekte für den Bezug in Frage kommen, dürfen konkrete oder abstrakte Objekt- oder Beziehungsklassen, jedoch keine Strukturen sein (da diese keine eigenständigen Objekte sind). Dabei kommen alle konkreten Klassen in Frage, die der aufgeführten primären bzw. einer der aufgeführten einschränkenden (RESTRICTION TO) Klassen entsprechen (Klasse selbst oder Unterklasse davon). Auf jeder Restriktionsstufe (Erstdefinition oder in Erweiterungsschritten) müssen jeweils alle noch zulässigen Klassen aufgeführt werden. Jede als Einschränkung definierte Klasse muss Unterklasse einer bisher zulässigen Klasse sein. Eine so in Frage kommende Klasse ist allerdings nur zulässig, wenn sie zum selben Thema wie das Referenzattribut oder zu einem Thema gehört, von denen das referenzierende Thema abhängig (DEPENDS ON) ist. Soll die Referenz auf ein Objekt eines anderen Behälters des gleichen oder eines anderen (DEPENDS ON vorausgesetzt) Themas verweisen dürfen, muss die Eigenschaft EXTERNAL angegeben werden. In Erweiterungen kann diese Eigenschaft weggelassen und damit ausgeschlossen, nicht aber zugefügt werden. Es muss mindestens eine zulässige konkrete Unterklasse geben, wenn das Referenzattribut nicht als abstrakt deklariert ist.

Die Werte von Strukturattributen bestehen aus einem oder mehreren Strukturelementen (Instanzen von Strukturen; vgl. Kapitel 3.5.3, “Klassen und Strukturen”). Strukturelemente haben keine OID, existieren nur im Zusammenhang mit ihrem Hauptobjekt und sind auch nur über dieses auffindbar. Die zulässige Anzahl der Strukturelemente ergibt sich aus der angegebenen Kardinalität bzw. dem vorhandenen oder abwesenden Schlüsselwort MANDATORY. Mit LIST kann man erreichen, dass die Strukturelemente in einer bestimmten Reihenfolge geführt werden. Diese Reihenfolge muss beim Transfer erhalten bleiben. Mit BAG sind die Strukturelemente ungeordnet.

Strukturattribute dürfen mit konkreten oder abstrakten Typen (Strukturen, Wertebereiche, Referenzattribute; aber keine Klassen) definiert werden.

Bei Strukturen ergibt sich der Aufbau durch die angegebene Struktur (Regel RestrictedStructureRef). Für die konkreten Strukturelemente kommen grundsätzlich alle Strukturen (nicht aber Klassen) in Frage, die der primären und den einschränkend (RESTRICTION TO) aufgeführten Strukturen entsprechen oder diese erweitern. Für die Strukturen des aktuellen Themas braucht es dafür keine weiteren Angaben. Strukturen anderer Themen werden nur berücksichtigt, wenn sie bzw. eine ebenfalls in diesem anderen Thema definierte Basisklasse als primäre oder einschränkende Struktur bei der Definition des Strukturattributes explizit aufgeführt ist. Auf jeder Restriktionsstufe (Erstdefinition oder in Erweiterungsschritten) müssen jeweils alle noch zulässigen Strukturen aufgeführt werden. Jede als Erweiterung definierte Struktur muss Erweiterung einer bisher zulässigen Struktur sein.

Ist die Struktur eines Strukturattributs beliebig (ANYSTRUCTURE) oder findet sich keine konkrete Struktur, die der Definition genügt, muss das Strukturattribut als abstrakt deklariert werden, sofern es obligatorisch ist bzw. eine minimale Kardinalität grösser null hat. Werden Strukturen als formale Funktionsargumente definiert (Kapitel 3.14, “Funktionen”) kommen als aktuelle Argumente Pfade zu Strukturelementen oder zu Objekten in Frage. Insbesondere sind mit ANYSTRUCTURE alle Strukturelemente und alle Objekte verträglich.

Eine geordnete Unterstruktur (LIST) darf nicht durch eine ungeordnete (BAG) erweitert werden. Für die Kardinalität gelten die gleichen Regeln wie bei Beziehungen (vgl. Kapitel 3.7.3, “Kardinalität”).

Eigentliche Beziehungen (im Gegensatz zu Referenzattributen; vgl. Kapitel 3.6, “Attribute”) werden als eigenständige Konstrukte beschrieben. Sie haben aber weitgehend gleiche Eigenschaften wie Klassen. So können sie selbst lokale Attribute und Konsistenzbedingungen aufweisen. Der Assoziationsname darf auch fehlen. Er wird dann implizit aus der Zusammensetzung der Rollennamen (erster, dann zweiter, usw.) gebildet. Die wichtigste Eigenschaft einer Beziehung besteht jedoch in der Auflistung von mindestens zwei Rollen mit den zugeordneten Klassen oder Beziehungen (Regeln wie bei den Referenzattributen, vgl. Kapitel 3.6.3, “Referenzattribute”) und den Detaileigenschaften wie Stärke der Beziehung und Kardinalität. Die Rollennamen sollen typischerweise Substantive sein. Sie können, müssen aber nicht, mit den Namen der zugeordneten Klassen oder Beziehungen übereinstimmen. Die zu definierende Beziehung darf aber nicht Erweiterung einer so zugeordneten Beziehung sein. Einer Rolle können auch alternativ verschiedene Klassen oder Beziehungen zugeordnet sein. Eine solche alternative Klasse oder Beziehung darf keine Erweiterung einer anderen alternativen Klasse oder Beziehung derselben Rolle sein.

Beispiel einer Beziehung, zwischen der Klasse K einerseits und den Klassen K oder L andererseits:

Beziehungen können primär wie Klassen erweitert werden. Damit die Bedeutung der Beziehung klar und unveränderlich ist, dürfen in Erweiterungen keine zusätzlichen Rollen beigefügt werden. Die zugeordneten Klassen oder Beziehungen und die Kardinalität können aber eingeschränkt werden. Unveränderte Rollen müssen nicht aufgeführt werden.

Beispiel, wie die Beziehung A zu A1 spezialisiert wird, wo nur noch Bezüge zu K1 (einer Subklasse von K) einerseits und zu K, L1, L2 (Subklassen von L) andererseits zulässig sind:

Ein Objekt der Klasse K1 kann damit entweder über eine Beziehung A mit Objekten der Klassen K oder L (zulässig, da K1 eine Subklasse von K ist) oder über eine Beziehung A1 mit Objekten der Klassen K, L1 oder L2 verbunden sein. Möchte man zusätzlich erreichen, dass ein Objekt K1 in der Rolle K nur die spezialisierte Beziehung A1 (und nicht auch die allgemeine Beziehung A) eingehen kann, ist die Rolle K als verdeckend (HIDING) zu kennzeichnen.

Dies ist allerdings nur zulässig, wenn für K1 keine anderen aus A erweiterten Beziehungen definiert sind, bei denen die Rolle K nicht als verdeckend gekennzeichnet ist.

Eine Instanz einer Beziehung zwischen Objekten kann als eigenständiges Objekt (Beziehungsinstanz) betrachtet werden. Primär werden auf dieser Beziehungsinstanz für alle Rollen die Bezüge zu den Bezugsobjekten festgehalten (alle müssen definiert sein!). Ohne weitere Angabe wird die Beziehungsinstanz durch die Bezüge zu den Objekten, die sie verbindet, identifiziert. Zwischen diesen Objekten ist dann nur eine solche Beziehungsinstanz zulässig. Mehrere Beziehungsinstanzen zwischen derselben Objektkombination sind nur zulässig, wenn für die Beziehung explizit eine Kardinalität mit Obergrenze grösser eins verlangt wird (CARDINALITY). In diesem Fall muss auch eine Objektidentifikation (mittels Property OID) verlangt werden. Wird eine eigene Objektidentifikation verlangt, kann die Beziehung auch selbst wieder in Rollen als Bezug verwendet werden.

Wird Kompatibilität mit INTERLIS 1 angestrebt, sollen nur Beziehungen mit zwei Rollen definiert werden, wobei die maximale Anzahl der Kardinalität einer Rolle nicht grösser als 1 sein darf.

Normalerweise müssen die konkreten Beziehungen zwischen Objekten mittels einer Anwendung explizit erstellt und dann durch das Bearbeitungssystem als Instanz festgehalten werden. Eine Beziehung kann aber auch aus einer Sicht abgeleitet werden, ohne dass sie instanziiert wird (DERIVED FROM). Eine solche Beziehung kann eine Erweiterung einer abstrakten Beziehung sein. Sie kann nicht selbst abstrakt sein. Wird sie erweitert, muss die Erweiterung auf der gleichen Sicht oder einer Erweiterung davon aufbauen. Allen Rollen und Attributen müssen entsprechend Objektpfade oder Attributpfade der Sicht zugewiesen sein. Dabei muss ein Objektpfad (vgl. Kapitel 3.13, “Ausdrücke”) angegeben werden, der letztlich eine der Rolle entsprechende Klasse oder Assoziation bezeichnet. Die Kardinalität muss mit der Leistung der Sicht übereinstimmen. Dies kann aber nur zur Laufzeit geprüft werden.

Ein typischer Anwendungsfall dürfte die Herleitung einer Beziehung aus den geometrischen Verhältnissen sein: In einer Sicht (Verbindung), auf die in der Assoziation Bezug genommen wird, werden z.B. Gebäude auf Grund der Geometrie mit den Liegenschaften, auf denen sie stehen, in Beziehung gebracht (vgl. Kapitel 3.15, “Sichten”).

In Anlehnung an UML werden verschiedene Beziehungsstärken unterschieden. Für ihre Erklärung wird vor allem beschrieben, welchen Einfluss die Beziehungsstärke beim Kopieren und Löschen von Objekten hat. Für INTERLIS 2 ist jedoch nur das Löschen von Objekten (als Folge der inkrementellen Nachlieferung) von Bedeutung. Darüber hinaus gibt es noch andere Überlegungen, die die Beziehungsstärke beeinflussen. Insbesondere ist es den Bearbeitungssystemen überlassen, feinere Beziehungsstärken oder gar andere Kriterien für das Verhalten bei bestimmten Operationen vorzusehen.

Assoziationen dürfen zu Aggregationen, diese zu Kompositionen erweitert werden, nicht aber umgekehrt.

Die Kardinalität definiert die minimale und die maximale Anzahl erlaubter Objekte; steht nur ein Wert, ist das Minimum gleich dem Maximum. Steht als Maximum ein Stern anstatt einer Zahl, gibt es keine obere Schranke für die Anzahl der Unterobjekte. Die Kardinalitätsangabe {*} ist äquivalent mit {0..*}. Falls die Kardinalitätsangabe weggelassen wird, gilt normalerweise {0..*}. Bei Kompositionsrollen ist nur {0..1} oder {1} zugelassen (ein Teil kann nur zu einem Ganzen gehören). Fehlt die Angabe gilt {0..1}.

Die Kardinalität darf in Erweiterungen nur eingeschränkt, nicht jedoch erweitert werden. Wird also zunächst eine Kardinalität von {2..4} angegeben, darf eine Erweiterung nicht {2..5}, {7} oder {*} deklarieren. Das Weglassen der Kardinalitätsangabe wird bei erweiterten Attributen als Übernehmen des ererbten Wertes verstanden.

Je nach Verwendung hat die Kardinalität folgende Bedeutung:

Will man erreichen, dass die Beziehung aus der Sicht einer bestimmten Bezugsklasse in einer bestimmten Ordnung geführt wird, muss dies bei der Rolle als Eigenschaft (ORDERED) verlangt werden. Diese Ordnung wird beim Etablieren der Beziehung definiert und muss bei Transfers erhalten bleiben.

Als Beziehungszugang (AssociationAccess) wird die Möglichkeit bezeichnet, aus der Sicht eines Objektes gemäss einer Beziehung zu den Beziehungsinstanzen und weiter zu den Bezugsobjekten zu navigieren. Beziehungszugänge müssen nicht definiert werden, sondern entstehen mit der Definition einer Beziehung für alle über Rollen zugeordneten Klassen, die im gleichen Thema wie die Beziehung definiert wurden. Ist eine an einer Beziehung beteiligte Klasse in einem anderen Thema definiert (themenübergreifende Beziehung) oder soll es zulässig sein, dass ein der Rolle entsprechendes Bezugsobjekt in einem anderen Behälter als die Beziehungsinstanz liegen darf, muss dies bei der Rolle speziell angemerkt werden (EXTERNAL, vgl. Kapitel 3.7.1, “Beschreibung von Beziehungen” und Kapitel 3.6.3, “Referenzattribute”). Die Klasse erhält dann keine Beziehungszugänge. Diese Eigenschaft wird in der Basisdefinition einer Beziehung festgelegt und kann in einer Erweiterung nicht mehr verändert werden. Bezieht sich eine Rolle auf eine vom geerbten Thema geerbte Klasse, sind Beziehungszugänge aus dieser Klasse nur möglich, wenn diese Klasse im aktuellen Thema mit gleichem Namen erweitert wurde (EXTENDED). Durch diese Einschränkungen wird vermieden, dass eine Klasse nachträglich (d.h. ausserhalb des Rahmens, in dem sie definiert wurde) nochmals eine Änderung erfährt.

Beziehungszugänge werden an die Subklassen vererbt, sofern dies nicht durch Verdeckungsforderung bei einer Rolle einer erweiternden Beziehung (HIDING) ausgeschlossen wird.

Beziehungszugänge sind für Pfadbeschreibungen von Bedeutung (vgl. Kapitel 3.13, “Ausdrücke”).

Eine Zeichenkette ist eine Folge von Zeichen mit einer maximalen Länge. Der Zeichenvorrat muss klar definiert sein (vgl. Anhang D Zeichentabelle).

Im Datentyp MTEXT sind die Zeichen «Carriage Return» (Wagenrücklauf) (#xD), «Line Feed» (Zeilenvorschub) (#xA) und «Tabulatorzeichen» (#x9), im Gegensatz zum Wertebereich des Datentyps TEXT, enthalten.

Beim Datentyp Zeichenkette (TEXT) ist primär die Länge der Zeichenkette von Interesse. Je nach der Form der Definition wird sie explizit oder implizit angegeben. Bei der expliziten Form (TEXT * …​) wird die maximale Länge in Anzahl Zeichen festgelegt (grösser Null). Werden nur die Schlüsselwörter TEXT oder MTEXT angegeben, ist die Anzahl Zeichen unbeschränkt. Im Rahmen einer Erweiterung kann die Länge verkürzt werden (eine Verlängerung würde zu einem Wertebereich führen, der mit dem Basis-Wertebereich nicht mehr verträglich ist).

Die INTERLIS-Zeichenkettenlänge bezeichnet die Zahl der Zeichen, wie sie von Benutzern wahrgenommen wird, nicht aber die Zahl der Speicherstellen, die ein System maximal zur Repräsentation einer Zeichenkette benötigt. Zeichenketten der Länge null gelten als undefiniert.

Bemerkung: Im Zusammenhang mit INTERLIS ist die Länge einer Zeichenkette als Anzahl jener Zeichen definiert, welche gemäss Unicode-Standard die kanonische Kombinationsklasse Nr. 0 besitzen, nachdem die Zeichenkette in die kanonisch dekomponierte Form von Unicode gebracht wurde (siehe https://www.unicode.org/unicode/reports/tr15/). So besitzt etwa eine Zeichenkette, die aus der Kette <LATIN CAPITAL LETTER C WITH CIRCUMFLEX><COMBINING CEDILLA> besteht, ebenso die Länge 1 wie die äquivalente Zeichenkette <LATIN CAPITAL LETTER C>< COMBINING CIRCUMFLEX ACCENT><COMBINING CEDILLA>. Gemäss der obigen Definition besitzen Ligaturen für «fl» oder «ffi» die Länge 1. Es wird aber davon abgeraten, solche Darstellungsformen überhaupt für Zeichenkettenattribute zu verwenden.

Der Namen-Zeichenkettentyp (Schlüsselwort NAME) definiert einen Wertebereich, der genau demjenigen der INTERLIS-Namen entspricht (vgl. Kapitel 3.2.2, “Namen”). Er wird in der vordefinierten Klasse METAOBJECT (siehe vordefiniertes Basismodell INTERLIS) und damit vor allem in den Klassen für Referenzsysteme sowie Signaturen eingesetzt (vgl. Kapitel 3.10.3, “Referenzsysteme” und Kapitel 3.16, “Darstellungsbeschreibungen”), weil dort Datenattribute mit Beschreibungselementen von Modellen übereinstimmen müssen.

Als weiterer Zeichenkettentyp wird der URI (Uniform Resource Identifier) geführt, z.B. http-, ftp- oder mailto-Adressen (s. Abschnitt 1.2 im Internet-Standard IETF RFC 2396 in https://www.w3.org). Die Länge eines URI ist in INTERLIS auf 1023 Zeichen beschränkt. Er entspricht damit folgender Definition:

Mit einer Aufzählung werden die für diesen Typ zulässigen Werte festgelegt. Die Aufzählung ist jedoch nicht einfach linear, sondern im Sinne eines Baumes strukturiert. Die Blätter des Baumes (nicht aber die Knoten) bilden die Menge der zulässigen Werte.

Eine Schachtelung wird in runden Klammern angegeben. Die Elementnamen jeder Schachtelung müssen eindeutig sein. Die Schachtelungstiefe ist frei wählbar.

Ist eine Aufzählung geordnet (Schlüsselwort ORDERED), ist eine Reihenfolge der Elemente definiert. Ist die Aufzählung zirkulär (Schlüsselwort CIRCULAR), ist die Reihenfolge der Elemente definiert, wie wenn die Aufzählung geordnet wäre. Zudem wird ausgesagt, dass nach dem letzten Element wieder das erste folgt.

Nebst der eigentlichen Aufzählungsdefinition ist es auch möglich, einen Wertebereich zu definieren, der als zulässige Werte alle Blätter und Knoten einer Aufzählungsdefinition umfasst (ALL). Einem solchen Attribut kann darum auch der Wert eines Attributs, der zu Grunde liegenden Aufzählungsdefinition zugewiesen werden.

Im Rahmen von Neudefinitionen von Aufzählungen (Primärdefinition, zusätzliche Elemente einer Erweiterung) darf das EnumElement nur aus einem Namen bestehen. Mehrere Namen sind nur zulässig, um für eine Erweiterung ein bisheriges Aufzählungselement zu identifizieren.

Aufzählungen können einerseits erweitert werden, indem für Blätter (also Aufzählungselemente, die keine Unter-Aufzählung aufweisen) der bisherigen Aufzählung Unter-Aufzählungen definiert werden. In der erweiterten Definition werden aus bisherigen Blättern neu Knoten, für die keine Werte definiert werden dürfen.

Andererseits kann jede einzelne Teilaufzählung in Erweiterungen durch weitere Elemente (Knoten oder Blätter) ergänzt werden. Die Basisaufzählungen umfassen dadurch nebst den genannten Elementen immer auch noch potenziell weitere Elemente, die erst in Erweiterungen definiert werden. Solche potenziellen Werte können auf der Basisstufe in Ausdrücken, Funktionsargumenten und Signaturzuweisungen (vgl. Kapitel 3.13, “Ausdrücke”, Kapitel 3.14, “Funktionen” und Kapitel 3.16, “Darstellungsbeschreibungen”) mit dem Wert OTHERS angesprochen werden. OTHERS ist jedoch kein zulässiger Wert im Rahmen der Klasse, zu der das Objekt gehört. Die Möglichkeit, in Erweiterungen zusätzliche Aufzählelemente anfügen zu können, kann unterbunden werden, indem die Teilaufzählung als abschliessend erklärt wird (FINAL). Dies erfolgt entweder nach dem letzten aufgeführten Element oder im Rahmen einer Erweiterung auch ohne dass neue Elemente angefügt werden.

Zirkuläre Aufzählungen (Schlüsselwort CIRCULAR) können nicht erweitert werden.

Für die Aufbereitung von Plänen und Karten müssen die Positionen von Texten festgehalten werden. Dabei muss festgelegt werden, welcher Stelle des Textes die Position entspricht. Mit dem horizontalen Alignment wird festgelegt, ob die Position auf dem linken oder rechten Rand des Textes oder in der Textmitte liegt. Das vertikale Alignment legt die Position in Richtung der Texthöhe fest.

Der Abstand Cap-Base entspricht der Höhe der Grossbuchstaben. Unterlängen befinden sich im Bereich von Base-Bottom.

Horizontales und vertikales Alignment können als folgende vordefinierte Aufzählung verstanden werden:

Der Typ Boolean weist die Werte false und true auf. Er kann als folgende vordefinierte Aufzählung verstanden werden:

Die wichtigste Angabe bei numerischen Datentypen ist der Minimal- und der Maximal-Wert inklusive Stellenzahl (Nachkommastellen) sowie der Skalierungsfaktor. Zusätzlich kann angegeben werden, dass der Typ zirkulär ist (Schlüsselwort CIRCULAR), d.h. dass der in der letzten signifikanten Stelle um 1 erhöhte Maximalwert und der Minimalwert sachlich die gleiche Bedeutung haben (z.B. bei Winkeln 0 .. 359 Grad). Ist das Attribut als eine kontinuierliche Unterteilung des Vorgängerattributs definiert (vgl. Kapitel 3.6.1, “Allgemeine Aussagen zu Attributen”), muss der Typ als zirkulär definiert sein. Fehlt die Angabe des Minimal- und Maximal-Wertes (Schlüsselwort NUMERIC), gilt der Wertebereich als abstrakt.

Die Stellenzahl muss beim Minimal- und beim Maximal-Wert übereinstimmen. Mit Hilfe der Skalierung können Float-Zahlen beschrieben werden, aber dann sind sowohl der Minimal- als auch der Maximal-Wert in Mantissendarstellung anzugeben, d.h. beginnend mit Null (0) und gefolgt vom Dezimalpunkt (.) muss die erste Ziffer nach dem Dezimalpunkt von Null (0) verschieden sein. Die Skalierung des Minimalwertes muss kleiner sein als die Skalierung des Maximalwertes. Die Schreibweise von Minimal- und Maximalwert bedeutet aber keineswegs eine Anweisung, wie die Werte transferiert werden sollen (ist ein Wertebereich mit 000 .. 999 definiert, bedeutet das nicht, dass der Wert 7 als 007 transferiert wird). Eine Ausnahme von dieser Regel bilden die Float-Zahlen. Diese sind in Mantissendarstellung und mit Skalierung zu transferieren.

Bei Erweiterungen dürfen die Maximal- bzw. Minimalwerte nur eingeschränkt werden. Der numerische Bereich wird damit also kleiner. Die Genauigkeit (Stellenzahl) darf nicht verändert werden.

Um die Bedeutung des Wertes genauer zu erklären kann eine Masseinheit angegeben werden (vgl. Kapitel 3.9, “Einheiten”). Abstrakte Masseinheiten sind nur zulässig, solange der Wertebereich selbst noch undefiniert ist (Schlüsselwort NUMERIC).

Für Erweiterungen gelten folgende Regeln:

Einem numerischen Wertebereich kann auch ein Skalarsystem zugeordnet werden (vgl. Kapitel 3.10.3, “Referenzsysteme”). Damit beziehen sich die Werte auf den durch das Skalarsystem bestimmten Nullpunkt. Es sind also absolute Werte in diesem Skalarsystem. Ist in der Klasse des Skalarsystems die Einheit nicht ANYUNIT, muss beim numerischen Datentyp eine Einheit angegeben werden, die mit jener des Referenzsystems verträglich ist. Bezieht man sich auf ein Koordinatensystem, kann die Achse angegeben werden, auf die sich die Werte beziehen. Die Einheit muss mit jener der entsprechenden Achse verträglich sein. Fehlt diese Angabe, ist der Bezug nicht genauer definiert, sondern ergibt sich aus dem Fachgebiet (z.B. bezieht man sich bei einer Höhe auf ein Ellipsoid, meint man ellipsoidische Höhen). Bezieht man sich auf einen anderen Wertebereich, soll das gleiche Referenzsystem gelten wie bei diesem Wertebereich. In diesem Fall darf die Angabe der Achse nur fehlen, wenn es sich um einen numerischen Wertebereich handelt. Bei einem Koordinatenwertebereich ist die Achsenangabe obligatorisch. Die Angabe des Referenzsystems kann in Erweiterungen nicht mehr geändert werden.

Stellt der numerische Wert einen Winkel dar, kann sein Richtungssinn festgelegt werden. Im Falle von Richtungen kann angegeben werden, auf welches Koordinatensystem (definiert durch einen Koordinaten-Wertebereich) sich die Richtung bezieht. Damit ist bekannt, wie die Nullrichtung (Azimut) und der Drehsinn definiert sind (vgl. Kapitel 3.8.8, “Koordinaten”). Diese Angabe kann in Erweiterungen nicht mehr geändert werden.

Als numerische Konstanten sind nebst den Dezimalzahlen auch die Zahlen Pi (Schlüsselwort PI) und e – Basis des natürlichen Logarithmus – (Schlüsselwort LNBASE) definiert.

Formatierte Wertebereiche basieren auf Strukturen und verwenden deren numerische oder formatierte Attribute in einem Format. Dieses Format dient einerseits dem Datenaustausch (vgl. 3.3.11.5 Codierung von formatierten Wertebereichen), andererseits der Definition von unterer und oberer Grenze des Wertebereichs.

Eine Basisdefinition eines formatierten Wertebereichs definiert primär die Struktur, auf welcher er aufbaut und das Format das zur Anwendung kommt. Zusätzlich können die untere und obere Grenze des Wertebereichs definiert werden. Sie dürfen die mit der Struktur definierten Grenzen nicht ausweiten.

Im Rahmen einer Erweiterung kann auf eine Erweiterung der ursprünglichen Struktur Bezug genommen, das Format ergänzt (der geerbte Teil muss am Anfang stehen und im Interesse von Klarheit mittels des Schlüsselwortes INHERITANCE erwähnt werden) und der Wertebereich eingeschränkt werden.

In der Formatdefinition können einerseits konstante Strings, die nicht mit einer Ziffer beginnen (am Anfang, am Ende und zwischen den einzelnen Attributreferenzen) und andererseits direkte oder indirekte Attributreferenzen (über Strukturattribute) enthalten sein. Die Attributreferenz muss entweder ein numerisches Attribut oder ein Strukturattribut bezeichnen. Im Falle eines numerischen Attributes können Vorkommastellen festgelegt werden. Als Folge ergeben sich nötigenfalls führende Nullen. Die Nachkommastellen ergeben sich aus dem numerischen Wertebereich. Bei Strukturattributen muss definiert werden, gemäss welchem formatierten Wertebereich es formatiert werden soll. Die Struktur muss mit der Basisstruktur des Wertebereichs übereinstimmen oder eine Erweiterung davon sein.

Wo Datums- oder Zeitangaben nicht nur aus einem einzigen Wert (z.B. Jahr, Sekunde) bestehen, werden üblicherweise formatierte Wertebereiche verwendet.

Die Wertebereiche für DATE, TIMEOFDAY bzw. DATETIME entsprechen den im Folgenden definierten INTERLIS.XMLDate, INTERLIS.XMLTime bzw. INTERLIS.XMLDateTime.

Im Interesse der Kompatibilität mit XML werden entsprechende Elemente durch INTERLIS vordefiniert:

Koordinaten können ein-, zwei- oder dreidimensional definiert werden und sind entsprechend eine Einzelzahl, ein Zahlenpaar oder ein Zahlentripel. Es ist zulässig, dass die zweite oder dritte Dimension erst in einer Erweiterung beigefügt wird. Für jede Dimension muss der numerische Wertebereich sowie allenfalls eine Masseinheit und ein Koordinatensystem (inkl. Achsnummern) angegeben werden. Es gelten die gleichen Regeln wie bei den numerischen Datentypen. Es können nur konkrete Masseinheiten angegeben werden. Wird kein Referenzsystem angegeben und sind die Masseinheiten entweder nicht oder als Längeneinheit definiert, darf ein Programmsystem, das das Modell implementiert, davon ausgehen, dass es sich um kartesische Koordinaten handelt.

Wird eine Rotationsangabe gemacht (Schlüsselwort ROTATION) kann im Rahmen von Richtungsdefinitionen (vgl. Kapitel 3.8.5, “Numerische Datentypen”) auf ein solches Koordinaten-Referenzsystem verwiesen werden. Die Rotationsdefinition legt fest, welche Achse des Koordinaten-Wertebereichs der Nullrichtung und welche der Richtung eines positiven, rechten Winkels entsprechen. Sie darf auch in einer konkreten Koordinatendefinition fehlen und dann allenfalls in einer Erweiterung beigefügt werden.

Die Angaben betreffend Achsbezug und Rotation können in Erweiterungen nicht geändert werden.

Mit der optionalen Angabe REFSYS kann der EPSG-Code^[5] des Referenzsystems gemäss dem Muster EPSG:PosNumber festgelegt werden.

Mit dem Schlüsselwort MULTICOORD statt COORD wird als Wertebereich eine ungeordnete Menge von Koordinaten definiert. Im Unterschied zu einer Formulierung mit LIST/BAG haben die einzelnen Werte aber zwingend dasselbe Referenzsystem.

Sind die Definitionen unvollständig, muss der Wertebereich entweder als abstrakt (Property ABSTRACT) oder als generisch (Property GENERIC) deklariert werden.

Bei abstrakten Koordinatenbereichen kann selbst die Anzahl Dimensionen offen bleiben. Abstrakte Wertebereiche können nur in Attributen verwendet werden, die als abstrakt deklariert sind. Abstrakte Koordinatenbereiche können dann auf verschiedene Arten konkretisiert werden.

Bei generischen Koordinatenbereichen muss die Anzahl der Dimensionen festgelegt sein. Es ist aber zulässig, dass dabei nur die Angabe NUMERIC gemacht wird. Generische Wertebereiche können auch in Attributen verwendet werden, die nicht als abstrakt deklariert sind. Generische Koordinaten-Wertebereiche können gleich wie abstrakte konkretisiert werden. Dabei werden insbesondere die numerischen Wertebereiche der Achsen und das Referenzsystem (Concrete-DomainRef) festgelegt bzw. eingeschränkt.

Das Thema (TOPIC), zu dem eine solche Definition gehört, muss aber als abstrakt deklariert werden, sofern keine Kontextdefinition wirkt.

Mit einer Kontextdefinition können für einen generischen Koordinaten-Wertebereich (Generic-CoordDef-DomainRef) konkrete Koordinaten-Wertebereiche definiert werden. Wurde für einen generischen Koordinaten-Wertebereich nicht nur ein einzelner, sondern eine Auswahl von möglichen konkreten Koordinaten-Wertebereichen festgelegt, wird beim Transfer des einzelnen Behälters, der für diesen Behälter geltende Wertebereich festgehalten (vgl. Kapitel 4.3.6, “Codierung von Themen”). Die Tatsache, dass die Festlegung aufgeschoben ist, muss beim Thema angemerkt werden (vgl. Kapitel 3.5.2, “Themen”). Der letztlich gültige konkrete Koordinaten-Wertebereich gilt bei allen Verwendungen des generischen Koordinaten-Wertebereichs und bei allen Verwendungen von Linien-Wertebereichen, die auf dem generischen Koordinaten-Wertebereich basieren.

Der Name des Kontexts ist ohne Bedeutung muss aber nach den allgemeinen Regeln eindeutig sein und dient z.B. für allfällige Fehlermeldungen. Ein Kontext wirkt in dem Modell wo er definiert wird und in allen Modellen, welche das definierende Modell direkt oder indirekt importieren.

Wirkt für einen bestimmten generischen Koordinaten-Wertebereich bereits eine Kontextdefinition, kann mit einer neuen Kontextdefinition für denselben generischen Koordinaten-Wertebereich eine neue Festlegung für den konkreten Wertebereich gemacht werden. Diese neuen Wertebereiche müssen aber Spezialisierungen der bestehenden Festlegungen sein.

Identifizierbare Objekte werden immer mit einer Objektidentifikation versehen. Damit für die Systeme klar ist, welcher Speicherplatz dafür vorgesehen werden muss und wie die Objektidentifikationen erzeugt werden müssen, können entsprechende Wertebereiche definiert und diese den Themen bzw. Klassen (vgl. Kapitel 3.5.2, “Themen” und Kapitel 3.5.3, “Klassen und Strukturen”) zugeordnet werden. Für die Verwaltung von Objektidentifikationen, insbesondere auch von Behältern, macht es aber Sinn, gewöhnliche Attribute mit solchen Wertebereichen zu führen.

INTERLIS 2 selbst definiert die folgenden OID-Wertebereiche (vgl. Anhang A Das interne INTERLIS-Datenmodell):

Es ist nicht möglich, eine OID-Definition zu erweitern, ausser dass ein NOOID durch ANYOID, und ANYOID zu einer konkreten Definition (nicht OID ANY) erweitert werden kann.

Wird ANYOID für abstrakte Themen bzw. Klassen angewendet, wird verlangt, dass eine Objektidentifikation erwartet wird, die genaue Definition aber noch offen ist. Sonst kann ANYOID nur als Wertebereich von Attributen verwendet werden. Zum Attributwert gehört dann nicht nur die eigentliche OID, sondern auch der konkrete OID-Wertebereich. OID-Werte von textlichen OID-Wertebereichen müssen die XML-ID Regel in Kapitel 4.3.1, “Einleitung” erfüllen: erstes Zeichen muss ein Buchstabe, eine Ziffer oder ein Unterstrich sein, dann folgen Buchstaben, Ziffern, Punkte, Minuszeichen, Unterstriche; keine Doppelpunkte (!).

Durch Einsatz dieses Datentyps können Attribute modelliert werden, deren Inhalt nicht spezifiziert werden kann. Die Variante XML beschreibt ein Attribut mit XML-Inhalt und die Variante BINARY einen binären Inhalt. Dieser Typ kann in Erweiterungen nicht verfeinert werden.

Es kann Sinn machen, dass Datenobjekte Verweise auf bestimmte Klassen und Attribute enthalten.

Mit der Angabe von STRUCTURE wird eine beliebige Struktur oder Klasse, mit CLASS (auch als Erweiterung von STRUCTURE zulässig) eine beliebige Klasse (aber keine Strukturen) zugelassen. Sollen nur bestimmte Strukturen bzw. Klassen und ihre Erweiterungen zugelassen sein, sind diese aufzuführen (RESTRICTION). In Erweiterungen müssen erneut alle zulässigen Strukturen bzw. Klassen aufgeführt werden. Sie dürfen aber nicht im Widerspruch zur Basisdefinition sein. Sobald solche Einschränkungen definiert sind, kann darum STRUCTURE nicht mehr durch CLASS erweitert werden.

Mit der Angabe von ATTRIBUTE wird ein Attributpfadtyp zugelassen. Es kann verlangt werden, dass es zu einer Klasse (keine Subklasse!) gemäss einer anderen Definition gehört (OF). Dabei kann entweder auf ein ClassType-Attribut oder im Falle einer Definition einer Funktion (vgl. Kapitel 3.14, “Funktionen”) auf ein anderes Argument verwiesen werden. Die möglichen Attributtypen können zudem eingeschränkt werden (RESTRICTION). Als Konstante kommen die Namen von Attributen der Klassen, Strukturen, Assoziationen und Sichten in Frage. Der entsprechende Klassenname kann explizit angegeben werden oder ergibt sich aus dem Kontext bzw. aus dem Verweis auf ein anderes Attribut oder ein anderes Argument (OF).

Basis-Einheiten sind Meter, Sekunden, etc. Sie brauchen keine weiteren Angaben mehr. Basis-Einheiten können aber auch abstrakt (Schlüsselwort ABSTRACT) definiert werden, wenn die Einheit selbst noch nicht bekannt ist, wohl aber der zu bezeichnende Gegenstand (z.B. Temperatur, Geld). Abstrakten Einheiten ist noch kein Kurzzeichen zugeordnet. Konkrete Einheiten können nicht mehr erweitert werden.

Durch INTERLIS selbst ist die abstrakte Einheit ANYUNIT definiert. Alle anderen Einheiten erben sie direkt oder indirekt (vgl. Kapitel 3.10.3, “Referenzsysteme”), ohne dass dies definiert werden muss. Folgende Einheiten sind durch INTERLIS direkt (d.h. intern) definiert:

Hinweis: Im Anhang H Einheiten-Definitionen sind die gebräuchlichsten Einheiten in einem erweiterten Typenmodell zusammengefasst.

Abgeleitete Einheiten sind durch Multiplikationen bzw. Divisionen mit Konstanten oder Funktion in eine andere Einheit umrechenbar.

Eine abgeleitete Einheit ist automatisch eine Erweiterung der gleichen abstrakten Einheit, wie diejenige in die sie umgerechnet werden kann.

Zusammengesetzte Einheiten (z.B. km pro h) ergeben sich durch Multiplikationen oder Divisionen von anderen Einheiten (Basis-Einheit, abgeleitete oder zusammengesetzte Einheit). Zusammengesetzte Einheiten können auch als abstrakte Einheiten definiert werden. Sie müssen sich dann vollständig auf andere abstrakte Einheiten beziehen.

Die bei der konkreten Erweiterung verwendeten Einheiten müssen dann konkrete Erweiterungen der in der abstrakten Definition verwendeten Einheiten sein.

Metaobjekte im Sinne von INTERLIS 2 sind Objekte, die im Rahmen der Beschreibung von Anwendungsmodellen von Bedeutung sind. Dies wird für Referenzsysteme und Grafiksignaturen genutzt.

Der Aufbau von Referenzsystem- oder Signaturobjekten muss in einem REFSYSTEM MODEL oder einem SYMBOLOGY MODEL mit den üblichen Mitteln von Klassen und Strukturen definiert sein. Referenzsystem-, Achsen- bzw. Signatur-Klassen müssen dabei Erweiterungen der durch INTERLIS angebotenen Klassen COORDSYSTEM, REFSYSTEM, AXIS bzw. SIGN sein, die ihrerseits Erweiterungen der Klasse METAOBJECT sind. Diese weist ein Attribut Name auf, das im Rahmen aller Metaobjekte eines Behälters eindeutig sein muss.

Für die eigentliche Beschreibung eines Anwendungsmodells wird das Metaobjekt selbst nicht gebraucht. Es genügt, den Namen als Stellvertreter des Metaobjektes zu kennen. Für ein laufendes System müssen die Metaobjekte jedoch in der Regel vollständig, also mit allen ihren Attributen, bekannt sein. Für ein Laufzeitsystem muss es darum klar sein, in welchem Behälter ein Metaobjekt mit einem bestimmten Namen enthalten ist. Damit Metaobjekte (bzw. ihre Namen) in Modellen verwendet werden können, müssen sie deklariert werden. Dabei wird ein Behältername eingeführt, das dabei vorausgesetzte Thema angegeben und dann (pro Klasse) die Namen der dort erwarteten Objekte aufgezählt (Regel MetaDataBasketDef). Der Behältername kann dabei auch als Erweiterung eines bereits eingeführten Namens definiert werden (EXTENDS). Das zugehörige Thema muss dann das gleiche wie beim Basisnamen oder eine Erweiterung davon sein.

Wird der Bezug auf ein Metaobjekt (Regel MetaObjectRef) unter dem erweiterten Behälternamen gemacht, muss der Name des Metaobjektes dort oder in einer geerbten Definition erwähnt sein. Von einem Laufzeitsystem wird das Metaobjekt zuerst im zugehörigen Behälter gesucht. Wird dort kein solches Metaobjekt gefunden, wird die Suche in den Behältern gemäss den direkt oder indirekt geerbten Behälternamen fortgesetzt. Damit können Metaobjekte in mehreren Stufen bereitgestellt und verfeinert werden. Zum Beispiel können zunächst allgemeine Grafiksignaturen definiert werden, die dann auf regionaler Stufe verfeinert und ergänzt werden. Wie der konkrete Behälter auf Grund des Behälternamens angesprochen werden kann, ist dabei Sache des eingesetzten Laufzeitsystems.

In einem übersetzten Anwendungsmodell (vgl. Kapitel 3.5.1, “Modelle”), kann einem Behälternamen auch ein konkreter Behälter zugewiesen werden, der nur Übersetzungen enthält (METAOBJECT_TRANSLATION Objekte; vgl. Anhang A Das interne INTERLIS-Datenmodell). Damit werden diejenigen Metaobjekte übersetzt, die durch den entsprechenden Behälter im zu Grunde liegenden Modell eingeführt wurden. Ist das zu Grunde liegende Modell selbst eine Übersetzung, kann auch da dem Behälternamen ein konkreter Behälter zugewiesen sein, der nur Übersetzungen enthält. Ist das Modell keine Übersetzung, kann einem Behälternamen nur ein konkreter Behälter zugewiesen werden, der keine Übersetzungen (d.h. keine METAOBJECT_TRANSLATION Objekte) enthält.

Wird im aktuellen Kontext nur ein Metadaten-Behältername benötigt, muss die Referenz auf den Metadatenbehälter (MetaDataBasketRef) in der Metaobjekt-Referenz nicht angegeben werden.

Mittels Parametern werden im Metamodell diejenigen Eigenschaften bezeichnet, die nicht das Metaobjekt selbst, sondern dessen Gebrauch in der Anwendung betreffen. Ihre Definition ist durch das Schlüsselwort PARAMETER eingeleitet und ist ähnlich aufgebaut wie diejenige der Attribute.

Ohne weitere Angaben sind numerische Werte und Koordinaten Differenzangaben; sie haben keinen definierten absoluten Bezug. Um dies zu erreichen, muss ein Koordinatensystem bzw. ein Skalarsystem definiert sein. Die Modelldefinition erfolgt dabei in einem REFSYSTEM MODEL. INTERLIS stellt dafür die folgenden Klassen zur Verfügung:

In Erweiterungen können weitere für die Art der Skalar- und Koordinatensysteme typische Attribute beigefügt werden und auch die Einheit durch eine Erweiterung ersetzt werden (Syntax für die Parameterdefinition vgl. Kapitel 3.10.2, “Parameter” und Kapitel 3.5.3, “Klassen und Strukturen”). Die in einem Wertebereich definierte Einheit muss dann mit ihr verträglich sein (vgl. Kapitel 3.9, “Einheiten”).

Jeder INTERLIS-Transfer kann aus dem dazugehörigen INTERLIS-Datenmodell durch die Anwendung von Regeln abgeleitet werden (modell-basierter Datentransfer).

Ein INTERLIS-Transfer ist ein sequentieller Objektstrom. Der Objektstrom ist in die Teile Vorspann und Datenbereich unterteilt.

Im Vorspann sind mindestens folgende Angaben zum Transfer enthalten:

Optional können im Vorspann Angaben zum Herausgeber des Objektidentifikatoren-Aufbaus erfolgen.

Optional können im Vorspann Kommentare enthalten sein.

Der Aufbau des Datenbereichs ist in den folgenden Abschnitten näher beschrieben.

Im Datenbereich können Objekte (d.h. Objektinstanzen) von konkreten Klassen, Beziehungen, Sichten und Grafikdefinitionen transferiert werden. Objekte von Sichten werden auf dem Transfer wie Objekte von konkreten Klassen behandelt. Die inkrementelle Nachlieferung von Sichten ist vorläufig nicht möglich. Objekte von Sichten werden nur transferiert, wenn die zugehörigen Sichten innerhalb eines VIEW TOPIC deklariert wurden, sonst werden sie nicht übermittelt. Ausserdem werden Sichten nicht übermittelt, wenn sie mit TRANSIENT markiert wurden.

Der Datenbereich besteht aus einer Folge von Behältern (Themen-Instanzen). Behälter können nur vollständig übertragen werden. Bei inkrementeller Nachlieferung werden nur die geänderten bzw. gelöschten Objekte übertragen. Zusammen mit der Vorgeschichte wird jedoch auch bei der inkrementellen Nachlieferung konzeptionell der ganze Behälter übertragen. Es ist grundsätzlich möglich, dass ein Transfer Behälter aus verschiedenen Modellen enthält. Ein Behälter enthält wiederum alle seine Objekte. Die Reihenfolge der Objekte im Transfer ist beliebig, insbesondere müssen die Objekte innerhalb eines Behälters nicht unbedingt nach Beziehungen geordnet oder nach Klassen gruppiert sein (im Gegensatz zu INTERLIS 1). Leere Behälter müssen nicht übertragen werden.

Im Objektstrom erhält jeder Behälter und jedes Objekt eine Identifikation. Die Identifikationen von Behältern und Objekten müssen über den gesamten Transfer eindeutig sein. Zu jedem Objekt wird ausserdem die Behälter-Identifikation mitgeliefert, in dem das Objekt ursprünglich erzeugt wurde (Originalbehälter). Bei inkrementeller Nachlieferung, bzw. beim initialen Transfer, muss die Identifikation des Behälters und der Objektinstanz generell und stabil sein, d.h. ein Objektidentifikator (vgl. Anhang F Aufbau von Objektidentifikatoren (OID)).

Alle Objektattribute (inkl. COORD, SURFACE, AREA, POLYLINE, STRUCTURE, BAG OF, LIST OF, etc.) werden unmittelbar zum Objekt gespeichert. Attribute vom Typ AREA werden wie Attribute vom Typ SURFACE codiert. Attribute vom Typ BAG werden wie Attribute vom Typ LIST codiert. STRUCTURE wird wie LIST {1} codiert.

Als Zeichenvorrat für die Übermittlung von Attributwerten stehen standardmässig nur die druckbaren Zeichen des US-ASCII Zeichensatzes (32 bis 126) und die Zeichen gemäss Anhang D Zeichentabelle zur Verfügung.

Zu jedem Behälter müssen folgende Angaben geliefert werden:

Es ist zulässig, dass im gleichen Transfer Behälter mit verschiedenen Transferarten (FULL, INTIAL und/oder UPDATE) vorkommen. Die Transferarten haben folgende Bedeutung:

Für die Transferart UPDATE gelten ausserdem folgende zusätzlichen Transferregeln:

Ausserdem muss zu jedem Objekt die Nachlieferungsoperation angegeben werden (vgl. Kapitel 2.4.5, “Behälter, Replikation und Datentransfer”). Die Operationen INSERT, UPDATE und DELETE bedeuten folgendes:

In vielen Fällen muss nicht ein ganzer Datenbestand, sondern nur ein Ausschnitt daraus transferiert werden. Als Folge der Ausschnittbildung können Geometrien (Polylinien und Flächen) unvollständig sein. Damit dies ohne ein zusätzliches Modell möglich ist, sollen Objekte (und als Folge der jeweilige Behälter) als INCOMPLETE markiert werden können.

In der nachfolgenden XML-Codierung bzw. Herleitung des XML-Schema wird auf diverse externe Dokumentationen verwiesen, welche hier zusammengefasst sind:

{1} W3C: XML 1.0 Spezifikation, Ausgabe 2008

{2} W3C: XML Schema 1.1 Spezifikation, Ausgabe 2012

{3} IETF: RFC 3629, UTF-8 Spezifikation

{4} IETF: RFC 2045, Abschnitt 6.8 (Base64 Codierung)

Im Gegensatz zu den Regeln in Kapitel 4.2, “Allgemeine Regeln für den sequentiellen Transfer” gelten die Regeln unter XML-Codierung nur für gemäss XML-1.0 Standard formatierte Transferdateien {1}. Für die Formalisierung der Transferformat-Ableitungsregeln wird die in Kapitel 3.1, “Verwendete Syntax” eingeführte EBNF-Notation benutzt. Folgende Regeln werden hier bereits vordefiniert:

Als Zeichenvorrat für XML-String bzw. XML-NormalizedString stehen standardmässig nur die ASCII Zeichen von 32 bis 126 bzw. die Zeichen aus Anhang D Zeichentabelle zur Verfügung. Die Zeichen werden gemäss der Codierungsregel UTF-8 {3} oder als XML Character Reference codiert.

Eine XML Entity Reference ist nur für wenige Spezialzeichen erlaubt. Der Wert ist eine ASCII-Zeichenfolge, welche genau so im Transfer verwendet werden muss. Bemerkung: XML-Entities wie &uuml; (für Zeichen ü) sind in einer INTERLIS 2-Transferdatei nicht erlaubt, weil von einer INTERLIS 2-Transferdatei keine Dokumenttypdefinition (DTD) referenziert wird.

Die benutzbaren XML Entities sind durch die XML 1.0 Spezifikation vordefiniert:

Eine vollständige Zusammenfassung der Zeichencodierung mit allen möglichen Codierungsformen pro Zeichen ist in Anhang D Zeichentabelle enthalten. Ein INTERLIS 2 Schreibprogramm kann bei mehreren Codierungsformen pro Zeichen eine geeignete Form frei auswählen. Ein INTERLIS 2-Leseprogramm muss alle Codierungsformen erkennen. Kommen im Transfer Zeichen vor, die nicht im beim Modell definierten Zeichensatz (vgl. Kapitel 3.5, “Modelle, Themen, Klassen”) vorkommen (oder gemäss Anhang D, wenn die Angabe des Zeichensatzes beim Modell fehlt), ist es der Software überlassen, wie sie damit umgeht (z.B. stillschweigend ignorieren oder mit Hinweis durch ein Ersatzzeichen ersetzen).

Bemerkung: Mehrere Codierungsformen pro Zeichen und Zeichen ausserhalb des evtl. eingeschränkten Zeichensatzes werden zugelassen um maximale Kompatibilität mit bestehenden XML-Werkzeugen zu erreichen.

Eine INTERLIS-Transferdatei ist gemäss folgender EBNF-Hauptregel aufgebaut:

Die Regel HeaderSection erzeugt den Vorspann der Transferdatei und die Regel DataSection den Datenbereich.

Eine durch die Transferregel erzeugte INTERLIS-Transferdatei ist immer auch eine wohlgeformte (well formed) XML 1.0-Transferdatei {1}. In einer INTERLIS-Transferdatei können daher auch beliebig viele Kommentarzeilen der Form

an den in XML 1.0 dafür vorgesehenen Stellen vorkommen. Der Inhalt der Kommentarzeilen %Comment% darf von der Transfersoftware jedoch nicht interpretiert werden.

Grundsätzlich ist ein INTERLIS 2 Schreibprogramm frei, welcher Prefix (%ili%, %geom%, %ns%) für welchen XML-Namespace verwendet wird, bzw. welcher XML-Namespace als default XML-Namespace verwendet wird. Mit %ns% ist der jeweilige XML-Namespace des INTERLIS-Modells gemeint, in dem das entsprechende Modellelement definiert wurde.

Das XML-Schema für den Namespace "http://www.interlis.ch/xtf/2.4/INTERLIS" wird im Anhang B definiert und für "http://www.interlis.ch/geometry/1.0" im Anhang C. Alle anderen XML-Schemas ergeben sich aus den Regeln gemäss Kapitel 4.4, “Herleitung des XML-Schema aus dem Datenmodell”.

Die Daten werden als XML-Objekte übertragen. Die Tagnamen der XML-Objekte werden jeweils aus den Objektnamen im INTERLIS-Datenmodell abgeleitet. Für übersetzte Datenmodelle (TRANSLATION OF) bleiben die Tagnamen in der Ursprungs-Sprache, d.h. das Transferformat ändert sich nicht.

Enthält das Modell eine explizite Namespace Definition (XMLNS; vgl. Regel ModelDef), wird diese übernommen. Andernfalls wird der Namespace aus "http://www.interlis.ch/xtf/2.4/" und dem ModelName gebildet.

Hinweis: Um die Lesbarkeit zu erhöhen und die Verarbeitbarkeit mit diversen Texteditoren zu verbessern, wird empfohlen die XML-Daten formatiert in die Transferdatei zu schreiben.

Der Vorspann ist wie folgt aufgebaut:

Unter models müssen die Hauptmodelle eingetragen werden zu welchen Objekte im Transfer vorkommen können. In %Comment% kann (optional) ein Kommentar angegeben werden, in dem der Transfer näher beschrieben wird.

Der Datenbereich ist wie folgt aufgebaut:

Behälter sind Instanzen eines konkreten TOPIC bzw. VIEW TOPIC. Behälter werden wie folgt codiert:

Der Wert %ns%:%TopicName% muss für jedes konkrete Topic entsprechend substituiert werden (z.B. Fixpunkte). Die XML-Attribute des Behälters haben folgende Bedeutung:

Die Objektinstanzen einer konkreten Klasse bzw. einer nicht eingebetteten Beziehung werden wie folgt codiert:

Der Wert %ClassName% muss für jede konkrete Klasse entsprechend substituiert werden (z.B. LFP). Jede Klasse – und damit jede Objektinstanz – erhält zusätzlich zu den im Modell definierten Attributen implizit eine Transferidentifikation (XML-Attribut tid). Die %Tid% muss wie eine XML-ID formatiert sein.

%TopicName% muss nur für Klassen / Beziehungen angeben werden, für welche ein Namenskonflikt mit Klassen / Beziehungen / Strukturen aus anderen Topics des gleichen Modells besteht.

Instanzen von Beziehungen (Link) haben nur eine Transferidentifikation, wenn diese im Rahmen der Definition mit dem Property OID gefordert wurde (vgl. Kapitel 3.7.1, “Beschreibung von Beziehungen”).

In der Transferart FULL müssen alle %Tid% innerhalb des gesamten Transfers eindeutig sein. In der Transferart INITIAL oder UPDATE müssen die %Tid% global eindeutige OID’s sein. Zudem erhält jedes Objekt in den Transferarten INITIAL und UPDATE ein Attribut für die Nachlieferungsoperation (XML-Attribut operation). Das XML-Attribut operation kann die Werte INSERT, UPDATE oder DELETE annehmen. Ohne Angabe von operation wird der Wert INSERT angenommen.

Mit DeleteObject kann bei inkrementeller Nachlieferung die Löschung eines bestimmten Objekts des Baskets über seine OID verlangt werden. Bei Beziehungen ohne OID wird die Instanz (Link) durch die Kombination der OIDs der bezeigten Objekte identifiziert. Bei DeleteObject müssen im Gegensatz zu operation="DELETE" keine weiteren Attribute des Objekts geliefert werden.

Für die Reihenfolge der Rollen, Attribute, Referenzattribute und eingebetteten Beziehungen innerhalb der Klasse gilt: Zuerst werden alle Rollen der Basisklasse, dann alle Attribute/Referenzattribute der Basisklasse, dann alle eingebetteten Beziehungen der Basisklasse, dann alle Attribute/Referenzattribute der Erweiterung, dann alle eingebetteten Beziehungen der Erweiterung codiert, etc. (Zwiebelprinzip). Innerhalb der gleichen Erweiterungsstufe werden die Attribute/Referenzattribute und Rollen gemäss ihrer Definitionsreihenfolge in der Modelldatei codiert. Die eingebetteten Beziehungen werden innerhalb der gleichen Erweiterungsstufe alphabetisch aufsteigend sortiert.

Parameter werden mit einer Ausnahme, wie sie im Kapitel 4.3.10, “Codierung von Grafikdefinitionen” angegeben ist, nicht übertragen.

Zur Codierung von Sichten vgl. Kapitel 4.2.3, “Transferierbare Objekte”. Es wird das XML-Attribut tid, nicht aber operation übermittelt. Als Attribute des Sichtobjekts werden nur diejenigen Attribute übertragen, welche in der Sicht explizit unter ATTRIBUTE bzw. implizit mit ALL OF angegeben wurden.

Beziehungen werden auf zwei Arten codiert: eingebettet oder nicht eingebettet. Eine eingebettete Beziehung wird als Sub-Element von einer, an der Assoziation beteiligten, Klasse codiert. Die Instanz einer nicht eingebetteten Beziehung (Link) wird wie eine Instanz einer Klasse codiert.

Beziehungen werden immer eingebettet, ausser

Falls bei einer der beiden (Basis-)Rollen die maximale Kardinalität grösser 1 ist, wird bei der Ziel-Klasse dieser Rolle eingebettet. Wenn diese Ziel-Klasse in einem anderen Topic definiert ist als die (Basis-)Assoziation, kann nicht eingebettet werden.

Falls bei beiden (Basis-)Rollen die maximale Kardinalität kleiner gleich 1 ist, wird bei der Ziel-Klasse der zweiten Rolle eingebettet. Wenn diese Ziel-Klasse in einem anderen Topic definiert ist als die (Basis-)Assoziation und die Ziel-Klasse der ersten Rolle im selben Topic definiert ist wie die (Basis-)Assoziation, wird bei der Ziel-Klasse der ersten Rolle eingebettet (d.h., wenn die Ziel-Klassen der beiden Rollen in einem anderen Topic definiert sind als die (Basis-)Assoziation, kann nicht eingebettet werden).

Für jede Grafikdefinition werden im Transfer die von der Grafikdefinition referenzierten Signaturklassen (Sign-ClassRef) übertragen. Die Objektinstanzen der Signaturklassen werden durch das Ausführen der Grafikdefinitionen auf einem konkreten Inputdatensatz erzeugt. Parameter werden dabei wie Attribute codiert.

Jede XML-Schema Datei (XSD) muss den Regeln gemäss {2} genügen. Ausserdem hat jede aus einem INTERLIS 2.4 Datenmodell abgeleitete XSD-Datei folgende Grundstruktur:

Die XSD-Datei besteht aus einem Header mit Angaben zum Modell (ModelName). Danach folgen die Deklarationen für Typen (TypeDef) und Klassen (ClassTypeDef) und schliesslich die Basketdefinitionen (BasketDef). Jedes XML-Schema für ein Interlis Modell importiert die externen XML-Schemas "http://www.interlis.ch/xtf/2.4/INTERLIS" (INTERLIS 2.4 Basisdefinitionen, s.a. Anhang B) und "http://www.interlis.ch/geometry/1.0" (INTERLIS Geometrieschema, s.a. Anhang C).

Das generierte XML-Schema kann beliebig viele Kommentare (<!-- … -->) oder zusätzliche xsd:annotation-Elemente enthalten. Das generierte XML-Schema darf das INTERLIS-Modell exakter, d.h. mit zusätzlichen «facets», umsetzen.

Alle Typen eines Modells (global oder auf Stufe Thema) werden wie folgt definiert:

Für alle Typen muss am Ende des Namen "Type" angehängt werden (z.B. LKoordType für den INTERLIS Typ LKoord). Für Typdeklarationen auf Stufe Thema muss den Typnamen zusätzlich %TopicName% vorangestellt werden (z.B. Bodenbedeckung.BBArtType), falls der Typname bereits auf Stufe Modell verwendet wurde.

Klassen, Strukturen und eigenständige Beziehungen werden wie folgt übersetzt:

Bei Klassen ist die Angabe des XML-Attributs TID obligatorisch. In Strukturen dürfen die Attribute TID und OPERATION nicht vorkommen.

Für die Reihenfolge der Attribute, Rollen und EmbeddedLink innerhalb der Klasse gilt: Die Attribute/Referenzattribute und Rollen werden gemäss ihrer Definitionsreihenfolge in der Modelldatei codiert. Die EmbeddedLink werden innerhalb der gleichen Erweiterungsstufe alphabetisch aufsteigend sortiert. Die Rollen, Attribute und EmbeddedLink, die von einer Basisklasse geerbt werden, werden nicht wiederholt.

Für Listen- und Bag-Attribute muss für %MinCard% die minimale bzw. für %MaxCard% die maximale Kardinalität eingegetragen werden.

Für alle übrigen Attribute ist %MaxCard% gleich 1. Für MANDATORY Attribute beträgt %MinCard% ebenfalls 1, sonst 0.

Eingebettete Beziehungen werden gemäss der Regel EmbeddedLinkDef definiert.

TypeDef für Attribute mit lokaler Typdeklaration werden ohne XSD-Attribut name ausgegeben.

Pro Thema wird folgende Definition ausgegeben:

Für Elementdefinitionen der Klassen innerhalb der BasketDef gilt: Zuerst werden alle Klassen der Basistopics, dann alle Klassen des Erweiterungstopics codiert, etc. (Zwiebelprinzip). Wobei Klassen des Erweiterungstopics nur codiert werden, wenn die Basisklasse nicht als Teil des Basistopics bereits codiert wurde.

Themen müssen in der XSD-Datei in der gleichen Reihenfolge wie im Datenmodell definiert werden.