INTERLIS 2.4 Referenzhandbuch

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 2.2.7 Sonderzeichen und reservierte Wörter) zusammenfallen, sind unzulässig.

Näheres zur Eindeutigkeit und zum Gültigkeitsbereich von Namen ist im Kapitel 2.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 2.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 2.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 2.16 Darstellungsbeschreibungen und Kapitel 2.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 3 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 2.8.1 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 3.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 3 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 3.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 2.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 2.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 2.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 2.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 2.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 2.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 2.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 2.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 2.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 2.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 2.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 2.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 2.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 2.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 2.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 (vgl. Kapitel 2.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 2.7.3 Kardinalität).

Eigentliche Beziehungen (im Gegensatz zu Referenzattributen; vgl. Kapitel 2.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 2.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 2.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 2.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 2.7.1 Beschreibung von Beziehungen und Kapitel 2.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 2.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 2.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 2.10.3 Referenzsysteme und Kapitel 2.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 2.13 Ausdrücke, Kapitel 2.14 Funktionen und Kapitel 2.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 2.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. Man beachte dabei folgende Situation:

Um die Bedeutung des Wertes genauer zu erklären kann eine Masseinheit angegeben werden (vgl. Kapitel 2.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 2.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 2.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 2.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 3.3.6 Codierung von Themen). Die Tatsache, dass die Festlegung aufgeschoben ist, muss beim Thema angemerkt werden (vgl. Kapitel 2.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 2.5.2 Themen und Kapitel 2.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 3.3.1 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 2.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 2.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 2.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 2.10.2 Parameter und Kapitel 2.5.3 Klassen und Strukturen). Die in einem Wertebereich definierte Einheit muss dann mit ihr verträglich sein (vgl. Kapitel 2.9 Einheiten).