5.4.2 Datenfluß

• Grammatik der Repräsentation der zwischen ArcView und MSL ausgetauschten Datentypen
• Repräsentation der MSL-Datentypen in Avenue
• Umwandlung von MSL-Daten-Objekten in Avenue-Objekte

In diesem Abschnitt soll der Datenfluß der Schnittstelle von Bausteinen mit ArcView-Kopplung zwischen dem MOBILE-Kernsystem und ArcView näher beschrieben werden.
In Abb. 28 ist das Zusammenspiel von Kontroll- und Datenfluß unter dem Aspekt der zeitlichen Abfolge dargestellt. Die Details des Datenflusses sind jedoch verborgen, um die Darstellung nicht zu unübersichtlich werden zu lassen. Zur Erläuterung des Datenflusses möchte ich in zunehmender Detaillierung vorgehen:
* Die Schnittstelle wird so beschrieben, wie sie sich für EntwicklerInnen von Bausteinen darstellt. Dies ist jedoch nicht als Anleitung zu verstehen, wie die Klassen zu benutzen sind, sondern vielmehrwie die beteiligten Klassen ihre Aufgaben erfüllen. Eine Anleitung zur Benutzung der Klassen ist weiter hinten im Abschnitt Leitfaden Programmierschnittstelle für Bausteine mit ArcView-Kopplung zu finden (S. 119).
* Die darunterliegenden Schichten der Schnittstelle werden beschrieben.
Ein MSL-Daten-Objekt kann in unterschiedlichen Repräsentationen vorliegen. Die im MOBILE-System ausschlaggebende Repräsentation ist die durch ein Java-Objekt, das von einer von Mobile.MSL.MSLData abgeleiteten Klasse instantiiert wurde. Diese wird im folgenden Java-Repräsentation genannt. MSL-Daten-Objekte werden in der Java-Repräsentation über die Eingabe- und Ausgabe-Ports zwischen einzelnen Bausteinen ausgetauscht bzw. als Parameter übergeben.
Für die Kopplung mit dem GIS ArcView gibt es zwei weitere Repräsentationen, die Austauschrepräsentation und die Avenue-Repräsentation, sowie eine Form, die ich nicht als Repräsentation bezeichnen möchte, da es zwar Entsprechungen gibt, die Avenue-Datentypen aber in viel stärkerem Maße Abweichungen haben. Während die Überführung aus einer Repräsentation in eine andere ohne Informationsverlust passiert, geht bei der Überführung eines MSL-Daten-Objektes Information verloren. Umgekehrt können aus Avenue-Daten-Objekten nur unter Zuhilfenahme von Voreinstellungen MSL-Daten-Objekte erzeugt werden, ferner sind auch nicht alle Avenue-Datentypen in MSL-Daten-Objekte überführbar.
Die der Java-Repräsentation in Avenue entsprechende Form ist die Avenue-Repräsentation. Sie hat als Grundlage die sehr flexiblen Avenue-Listen, deren erstes Element ein MSL-Daten-Typbezeichner ist. Der Aufbau der Avenue-Repräsentation ist im Abschnitt Repräsentation der MSL-Datentypen in Avenue, (S.112) beschrieben.
Die Austauschrepräsentation von MSL-Daten-Objekten dient dem Austausch in einem Datenformat, welches sowohl Java als auch Avenue lesen und schreiben können.
Die folgende Abbildung zeigt den Datenfluß eines MSL-Daten-Objekts für den eher hypothetischen Fall, daß es aus dem Java-setigen Teil eines Bausteins zum GIS ArcView und zurück konvertiert wird. Durchläuft ein in Java-Repräsentation vorliegendes Objekt (in der Abbildung Obj1 genannt) nur die durchgezogenen Pfeile des Datenflusses, so liegt es nach dem Weg zur Avenue-Repräsentation und zurück als Klon des Originals, d.h. als Original und Kopie, vor.
Nimmt es hingegen den Weg entlang des gestrichelt eingezeichneten Datenflusses über die Form als Avenue-Objekt, so liegt es hinterher im allgemeinen nicht als Klon vor. Dies liegt daran, daß nicht alle MSL-Daten-Typen eine sinnvolle Entsprechung in Avenue-Datentypen haben und bei ihrer Konvertierung in ein Avenue-Objekt Information verloren geht. Diese nicht verlustfreie Konvertierung wird im Folgenden extrizieren genannt, der umgekehrte Vorgang intrizieren. Erläuterung siehe weiter unten.

Nicht jedes MSL-Daten-Objekt sind nach ArcView übertragbar. Die erste Einschränkung wird aufgrund seines Typs gemacht. Sie ist unter anderem aus der Grammatik der Austauschrepräsentation zu entnehmen. Vom MOBILE-Kernsystem nach ArcView und zurück konvertierbar sind alle dort als NonRecursiveType definierten MSL-Daten-Typen sowie Matrix, Table und UntypedMatrix. Der Hilfstyp Row dient der Vereinfachung der Grammatik, ist kein MSL-Daten-Typ und nicht konvertierbar.
Ein Konzept der Schnittstelle zwischen dem MOBILE-Kernsystem und ArcView lautet, daß alle in der Java-Repräsentation der MSL-Daten-Objekte zugreifbaren Daten auch in Avenue-Scripten zugreifbar sein sollen. Dies wurde in der Avenue-Repräsentation umgesetzt.
Es ist aber einerseits nicht immer notwendig, alle Details verfügbar zu haben, andererseits ist der Zugriff auf die Listenstrukturen der Avenue-Repräsentation nicht besonders komfortabel.
Um den Mangel an Komfort zu beheben, wurde eine weitere Stufe der Konvertierung auf der ersten aufgebaut, die den Schwerpunkt auf Programmierkomfort und nicht auf Informationserhaltung legt.
Nicht alle MSL-Daten-Objekte mit konvertierbarem MSL-Daten-Typ sind extrizierbar bzw. intrizierbar. Extrizieren[19] und intrizieren sind Kunstwörter, die die Situation hervorheben sollen, daß es sich bei der Konvertierung aus einer Repräsentation in ein Avenue-Objekt um eine Konvertierung mit Informationsverlust bzw. Erstellung unter Zuhilfenahme von Standardannahmen handelt. Konvertierbar bedeutet also genauer zwischen den Repräsentationen verlustfrei konvertierbar.
Insofern liegt eine weitere Einschränkung der Menge der konvertierbaren MSL-Daten-Typen bei der Konvertierung aus der Java-Repräsentation in ein Avenue-Objekt und umgekehrt vor.
Ist der Informationsverlust, der beim Extrizieren erfolgt, im Einzelfall nicht tragbar, so kann immer noch auf die Avenue-Repräsentation zurückgegriffen werden.
Nicht für alle MSL-Daten-Typen ist es sinnvoll, eine komfortable Umwandlung in ein Avenue-Objekt bereitzustellen. Unsinnig ist eine komfortable Umwandlung dann, wenn
* die Avenue-Repräsentation nicht allzu kompliziert ist, also etwa nur eine einfache Avenue-Liste, so daß sich der Zugriff nicht wirklich vereinfachen würde und
* der Informationsverlust für alle Zustände des MSL-Daten-Objekts so groß ist, daß das extrizierte Objekt nicht mehr von einem extrizierten Objekt eines anderen Typs unterschieden werden kann.
Zum Beispiel ist die extrizierte Form von Mobile.MSL.RealNumber der Avenue-Typ Number.
Die extrizierte Form von Length wäre ebenfalls Number, da es keinen entsprechenden Avenue-Typen gibt. Somit wären extrizierte Length-Objekte nicht mehr von extrizierten RealNumber-Objekten zu unterscheiden. Würde andererseits das unterscheidende Datum, die Maßeinheit, weiter mitgeführt, so wäre dies nur in einer Liste möglich, die wiederum nicht komfortabler zugreifbar wäre als die Avenue-Repräsentation von Length.
Eine Liste der extrizierbaren und intrizierbaren MSL-Daten-Typen sowie die damit verbundenen Informationsverluste bzw. Standardannahmen sind dem gleichnamigen Abschnitt auf (S. 116) zu entnehmen.
Der Ausführung eines Avenue-Scripts und der damit verbundenen Konvertierung dienen Java-seitig die Methoden ParameterList.add() und get() sowie ArcView.execute() aus dem package Mobile.GIS.ArcView. Dem stehen Avenue-seitig MobileReadAll und MobileWriteAll gegenüber, hinzu kommen die mit "MobileExtricate" beginnenden und die mit "MobileIntricate" beginnenden Avenue-Scripte. Im folgenden soll der darunterliegende Mechanismus, der die Konvertierung zwischen den Repräsentationen sowie das Extrizieren und Intrizieren als Vorgang beschrieben werden. Er ist in Abb. 30 illustriert.
Die Anwendung der genannten Klassen ist, wie bereits erwähnt, im entsprechenden Leitfaden zu finden.
Die Klasse ParameterList hat zum Zweck, eine Auswahl von zu übertragenden Objekten festzulegen. Objekte werden unter Angabe eines Namens in ein Objekt der Klasse ParameterList mittels .add() hinzugefügt.
Anschließend wird dieses ParameterList-Objekt als ein Argument des Aufrufs der Methode ArcView.executeScript() übergeben. In
ArcView.executeScript()
wird die Liste an ArcViewData.transferTo() übergeben. Hier wird nacheinander jedes Objekt wieder aus der Parameterliste entnommen und konvertiert. Dazu wird Convert.EveryType.to() aufgerufen. Es ist ein allgemeiner Konverter für alle gemäß obigen Definition konvertierbaren MSL-Daten-Typen. Er ruft seinerseits einen speziellen Konverter auf für einen MSL-Daten-Typ. Wenn es sich um einen komplexen MSL-Daten-Typ handelt, also einen, dessen Komponente ein anderer MSL-Daten-Typ ist, so wird im Verlauf der Konvertierung des MSL-Daten-Objekts durch den speziellen Konverter ein weiterer spezieller Konverter aufgerufen, der diese Komponente übersetzt. So ruft etwa
Convert.Polyline.to()
Convert.Point.to()
auf, welches wiederum
Convert.Realnumber.to()
aufruft. Beim Aufruf eines speziellen Konverters wird die Zeichenfolge, die das MSL-Daten-Objekt repräsentiert, so Stück für Stück zusammengesetzt. Der Grammatik der Austauschrepräsentation von Polyline etwa läßt sich entnehmen, daß die Austauschrepräsentation von MSL-Point-Objekten ein Bestandteil der Austauschrepräsentation von Polyline ist.
Nachdem die ein MSL-Daten-Objekt repräsentierende Zeichenfolge aufgebaut ist, wird sie in eine Datei mit dem gleichen Namen, unter dem das MSL-Daten-Objekt in der Parameterliste abgelegt wurde, geschrieben.
Nachdem alle Objekte aus der Parameterliste in eine Datei geschrieben wurden, ist die Aufgabe von ArcViewData.transferTo() beendet und die Ausführung des die Austauschrepräsentation konsumierenden, zum Baustein korrespondierenden Avenue-Scripts wird, wie bereits im Abschnitt Kontrollfluß (S. 89) beschrieben, gestartet.
Das korresponierende Avenue-Script muß als erstes die Anweisung
ParameterList = av.Run("MobileReadAll", SELF)
enthalten. Sie startet das Script MobileReadAll, welches nacheinander alle Dateien mit den Austauschrepräsentationen liest. Die im Argument SELF enthaltene Zahl gibt die Anzahl der MSL-Daten-Objekte in der Parameterliste weiter. MobileReadAll startet für jede Datei einmal das Avenue-Script MobileRead. Es liest die Datei und parst ihren Inhalt. Als erstes erkennt MobileRead den Typ des repräsentierten MSL-Daten-Objekts und ruft einen entsprechenden speziellen Konverter auf, der analog zum eben erläuterten Schema der Erstellung der Austauschrepräsentation wiederum für die Komponenten zur Zerlegung der Austauschrepräsentation weitere spezielle Konverter aufrufen kann. MobileRead gibt an MobileReadAll eine Liste zurück, die in ihrer Struktur der Austauschrepräsentation des konvertierten MSL-Daten-Objektes entspricht (vgl. Repräsentation der MSL-Datentypen in Avenue, S. 112). MobileReadAll fügt diese Liste unter dem Namen des Objekts, der dem Dateinamen der Austauschrepräsentation entspricht, in ein Avenue-Objekt vom Typ Dictionary ein. So werden nacheinander alle Objekte der Java-seitigen Parameterliste in das Dictionary eingefügt, so daß sie im korrespondierenden Avenue-Script wieder unter dem Namen entnommen werden können, unter dem sie Java-seitig eingefügt wurden. Ein entsprechender Mechanismus erhält die Gleichheit der Namen auch auf dem umgekehrten Weg, so daß auf diese Weise ein Java- wie Avenue-seitig gleicher Namensraum erzeugt werden kann. Ein Beispiel für die Anwendung findet sich im Abschnitt Die Kopplung des SimpleEmissionModel mit ArcView als Anwendungsbeispiel (S, 126).
Der umgekehrte Konvertierungsweg ist, trotz gleicher Funktionalität, nicht völlig identisch aufgebaut. MobileWriteAll funktioniert noch analog zu eben erfolgter Beschreibung: die Avenue-Repräsentationen der MSL-Daten-Objekte müssen in ein Avenue-Dictionary unter Angabe eines Namens abgelegt und an MobileWriteAll übergeben werden. MobileWriteAll konvertiert alle darin enthaltenen Objekte unter zuhilfenahme des allgemeinen Konverters MobileWrite, welcher typabhängige spezielle Konverter benutzt.
Die Konvertierung aus der Austauschrepräsentation mittels
ArcViewData.transferFrom()
greift über
EveryType.from()
jedoch auf die Klasse
ExchangeRepresentationParser
zu. Die ist ein mit Hilfe des Parsergenerators JavaCC erzeugter Parser.
JavaCC erwartet als Eingabe die Beschreibung des Parsers, und zwar sowohl der lexikalischen Analyse als auch des Parsers in einer Datei, in diesem Fall ExchangeRepresentationParser.jj. JavaCC erzeugt daraus bei jedem Übersetzen von ExchangeRepresentationParser.jj die Dateien
* ExchangeRepresentationParser.java
* ExchangeRepresentationParserConstants.java
* ExchangeRepresentationParserTokenManager.java
und, sofern sie noch nicht erzeugt wurden,
* ASCII_CharStream.java
* Token.java
* ParseError.java
Diese Java-Quelldateien müssen anschließend mit dem JDK-Werkzeug javac in .class-Dateien übersetzt werden.
Die Beschreibung des Parsers erfolgt in einer an die Erweiterte Backus Naur Form angelehnten Metagrammatik. Beschrieben werden sogenannte Tokens für die lexikalische Analyse und Produktionen für den Parser selbst. Damit nicht nur eine Zeichenfolge als korrekte Eingabe erkannt, sondern auch ein MSL-Daten-Objekt generiert werden kann, bietet JavaCC die Möglichkeit, Java-Quellcode in die Produktionen einzubinden.
Wird ein Token erkannt, so kann die es repräsentierende Zeichenteilfolge (das sogenannte Tokenimage) zum weiteren Aufbau der Java-Repräsentation des MSL-Daten-Objektes verwendet werden, dessen Austauschrepräsentation gerade geparst wird. Dazu kann Java-Quellcode, der die den Tokens entsprechenden Zeichenfolgen (Tokenimages) auswertet, in bestimmter Form in die Beschreibung der Produktionen hineingeschrieben werden. Dieser Java-Quellcode wird dann bei der Übersetzung der *.java-Dateien aus ExchangeRepresentationParser.jj in die Java-Methoden eingefügt, die den Produktionen entsprechen. Letztlich wird in EveryType.from() ein ExchangeRepresentationParser-Objekt wie von einer gewöhnlichen Java-Klasse instantiiert. Es erhält als Eingabe die Zeichenfolge (einen FileInputStream), die aus der Datei stammt, die die Austauschrepräsentation des zu transferierenden MSL-Daten-Objekts enthält.
Die Methoden des ExchangeRepresentationParser entsprechen in ihrer Funktion den speziellen Konvertern.
Eine Beschreibung des Werkzeugs JavaCC befindet sich unter[Sun98a].

Die Pfeile von StreetName und von StreetLength zu den Klassen der Programmierschnittstelle sind aus Gründen des Übersichtlichkeit nicht eingezeichnet.

Grammatik der Repräsentation der zwischen ArcView und MSL ausgetauschten Datentypen

Die Notation erfolgt in Erweiterter Backus-Naur-Form. (s[Sch93a],[Bro93], S. 661)
Fett gesetzte Zeichen gehören zur Metasyntax. Terminalsymbole sind normal gesetzt, Nichtterminalsymbole sind kursiv gesetzt. * bedeutet n-fache Wiederholung mit n> =0 . + bedeutet n-fache Wiederholung mit n>0
character sind alle Zeichen der auf dem erweiterten ASCII-Zeichensatz basierenden Zeichen mit Ausnahme von NewLine (ASCII 10Hex) und CarriageReturn(ASCII 13Hex). Sie spielen in der zugrundeliegenden Übertragung von Dateien eine besondere Rolle und müssen, wenn sie in Zeichenketten benötigt werden, durch "\n" und "\c" repräsentiert werden. Desweiteren werden Anführungszeichen """ durch "\"" und der rückwärts geneigte Schrägstrich (Backslash) "\" durch "\\" dargestellt.
digit ::= 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9
Text ::= Text=({character⁺ })
Boolean ::= Boolean=(true | false)
RealNumber ::= RealNumber=( [+ | -]digit ⁺ [.digit ⁺[E[+ | -] digit ⁺] ])
Angle ::= Angle=(RealNumber; Text )
Length ::= Length=(RealNumber; Text )
Duration ::= Duration=(RealNumber; Text )
TrafficFlow ::= TrafficFlow=(RealNumber; Text )
Velocity ::= Velocity=(RealNumber; Text )
Weight ::= Weight=(RealNumber; Text )
Concentration ::= Concentration=(RealNumber; Text , Text )
EmissionFactor ::= EmissionFactor=(RealNumber; Text , Text )
EmissionRate ::= EmissionRate=(RealNumber; Text , Text )
Point ::= Point=(RealNumber ; RealNumber )
Point3D ::= Point3D=(RealNumber ; RealNumber ; RealNumber )
Polyline ::= Polyline=(Point [; Point ]^*)
Polygon ::= Polygon=(Point [; Point ]^*)
NonRecursiveType ::= Angle | Boolean | Concentration | Duration | EmissionFactor | EmissionRate | Length | Point | Point3D | Polygon | Polyline | RealNumber | Text | TrafficFlow | Velocity | Weight
Row ::= Row=(NonRecursiveType [; NonRecursiveType ]^*)
UntypedMatrix ::= UntypedMatrix=(Row [;Row ]^*)
Matrix ::= Matrix=(Text; UntypedMatrix)
Table ::= Table=( Boolean; Text; Text; Row; Row; UntypedMatrix )

Repräsentation der MSL-Datentypen in Avenue

Die hier verwendete Syntax ist an die übliche Schreibweise von Listen in Avenue-Script-Code angelehnt. Zur Definition von Avenue-Listen siehe "working with lists and dictionaries" in[ESR95b].
Diese Syntax ist jedoch erweitert um Indices in mathematischer Schreibweise, die hier tiefgestellt gedruckt werden (Beispiel: aNumber_n-1).
Der MSL-DatenTyp-Bezeichner ist stets als erstes Listenelement in Form einer Zeichenkettenkonstante zu finden. Desweiteren werden Variablenbezeichner verwendet, die aus dem Buchstaben "a" und einem Avenue-Typbezeichner bestehen, und zwar: Number, String, Boolean, Point, Polyline, Polygon, Table.
Beispiel:
{"Point", aPoint}
ist eine Liste, die als erstes Element die Zeichenkettenkonstante "Point" enthält und als zweites Element eine Avenue-Variable vom Avenue-Typ Point.
Zur Verdeutlichung der Bedeutung eines Elements kann zwischen dem "a" und dem Avenue-Typbezeichner noch ein der Bedeutung entsprechendes Wort eingefügt sein:
Beispiel:
{"Concentration", aRealNumber, aUnitString, aPollutantString}
Die Zeichenkette aUnitString repräsentiert das Feld Unit im MSL-Datentyp, die Zeichenkette aPollutantString repräsentiert das Feld Pollutant.
Der Mobile.MSL.Datentyp, dessen Avenue-Repräsentation zu definieren ist, ist jeweils fett gedruck.
Mobile.MSL.Text
{"Text", aString}
Mobile.MSL.Boolean
{"Boolean", aBoolean}
Mobile.MSL.RealNumber
{"RealNumber", aRealNumber}
Mobile.MSL.Angle
{"Angle", aRealNumber, aUnitString}
Mobile.MSL.Length
{"Length", aRealNumber aUnitString}
Mobile.MSL.Duration
{"Duration", aRealNumber, aUnitString}
Mobile.MSL.TrafficFlow
{"Velocity", aRealNumber, aUnitString}
Mobile.MSL.Velocity
{"Velocity", aRealNumber, aUnitString}
Mobile.MSL.Weight
{"Weight", aRealNumber, aUnitString}
Mobile.MSL.Concentration
{"Concentration", aRealNumber, aUnitString, aPollutantString}
Mobile.MSL.EmissionFactor
{"EmissionFactor", aRealNumber, aUnitString, aPollutantString}
Mobile.MSL.EmissionRate
{"EmissionRate", aRealNumber, aUnitString, aPollutantString}
Mobile.MSL.Point
{"Point", aRealNumber, aRealNumber}
Mobile.MSL.Point3D
{"Point3D", aRealNumber , aRealNumber , aRealNumber}
Mobile.MSL.Polyline
Für Polyline und analog für Polygon gibt es zwei Varianten abhängig davon, ob die Polylinie nur zweidimensionale oder nur dreidimensionale Punkte enthält. Im dreidimensionalen Fall gibt der Index n die Anzahl der Punkte in der Polylinie bzw. dem Polygon wieder.
Es sind nur zweidimensionale Punkte in der Polyline enthalten:
{"Polyline", aPolyline}
Es sind nur dreidimensionale Punkte in der Polyline enthalten:
{"Polyline", aPolyline, aPoint₀, ... , aPoint_n-1}
Mobile.MSL.Polygon
Siehe auch die Anmerkung zu Polyline.
Sind nur zweidimensionale Punkte enthalten:
{"Polygon", aPolygon}
Sind nur dreidimensionale Punkte enthalten:
{"Polygon", aPolygon, aPoint₀, ... , aPoint_n-1}
Mobile.MSL.UntypedMatrix
Alle Elemente in der Avenue-Repräsentation einer UntypedMatrix sind Avenue-Listen, die der Avenue-Repräsentation eines nichtrekursiven Typs im Sinne des NonRecursiveType der Grammatik der Austauschrepräsentation entsprechen müssen. Diese werden in der folgenden Definition als aNonRecursiveTypeAvR abgekürzt.
{"UntypedMatrix",

}
Mobile.MSL.Matrix
Im Gegensatz zu einer UntypedMatrix müssen alle Elemente einer Matrix des gleichen (nichtrekursiven) Typs sein. Die Avenue-Repräsentation einer Matrix beruht auf der einer UntypedMatrix sowie der Angabe des Typs, der für alle Elemente gleich sein muß.
{"Matrix", aTypeString, anUntypedMatrixAvR}
Mobile.MSL.Table
Die Avenue-Repräsentation eines Table besteht aus
* der Angabe, ob es sich um einen spaltenorientierten Table handelt,
* einer Zeichenfolge, die den gemeinsamen Spaltentitel angibt
* einer Zeichenfolge, die den gemeinsamen Zeilentitel angibt
* einer Liste von Zeichenfolgen, die die Linientitel enthalten
* einer Liste von Zeichenfolgen, die die Linientypen enthalten
* der Avenue-Repräsentation einer UntypedMatrix
{"Table",
aColumnOrientationBoolean,
aCommonColumnsString,
aCommonRowString,
{aLineTitleString_0,0, aLineTitleString_1,0, ..., aLineTitleString_n-1,0},
{aLineTypeString_0,0, aLineTypeString_1,0, ..., aLineTypeString_n-1,0},
anUntypedMatrixAvR
}

Umwandlung von MSL-Daten-Objekten in Avenue-Objekte

Die folgenden MSL-Daten-Typen sind konvertierbar, aber nicht extrizierbar:
Mobile.MSL.Angle
Mobile.MSL.Length
Mobile.MSL.Duration
Mobile.MSL.Velocity
Mobile.MSL.TrafficFlow
Mobile.MSL.Weight
Mobile.MSL.Concentration
Mobile.MSL.EmissionFactor
Mobile.MSL.EmissionRate
Mobile.MSL.UntypedMatrix
Mobile.MSL.Matrix
Ohne Verlust extrizierbare MSL-Daten-Typen sind
Mobile.MSL.Text
Mobile.MSL.Boolean
Mobile.MSL.RealNumber
Mit Verlust extrizierbare MSL-Daten-Typen sind
Mobile.MSL.Point
Mobile.MSL.Point3D
Mobile.MSL.Polyline
Mobile.MSL.Polygon
Die Angabe der dritten Dimension eines (jeden) Punktes geht verloren.
Mobile.MSL.Table
Ein in der spaltenorientierten Form eventuell vorhandener gemeinsamer Spaltentitel wird der Titel der Tabelle, ein eventuell vorhandener gemeinsamer Zeilentitel entfällt. Ein MSL.Table in der zeilenorientierten Form kann nicht extriziert werden, da diese Form einerseits selten vorkommt und andererseits vollständig substituiert werden kann: Er ist daher zuvor Java-seitig in die spaltenorientierte Form zu überführen.
Linienüberschriften werden demzufolge zu Überschriften der Spalten, in Avenue sind dies die Namen der Fields. Da Field-Namen nur eine begrenzte Länge aufweisen können, werden zusätzlich noch die Fieldalias-Namen eingesetzt.
Nur bestimmte konvertierbare MSL-Daten-Typen dürfen in Avenue-Repräsentationen zu extrizierender Mobile.MSL.Table-Objekte vorkommen. Es sind dies genau die extrizierbaren MSL-Daten-Typen .
Wenn die Eigenschaften der komfortablen Konvertierung mittels Extrizierung nicht ausreichen, bleibt für spezielle Fälle noch die Möglichkeit, direkt auf die Avenue-Repräsentation für MSL-Daten-Objekte zurückzugreifen und diese speziell in Avenue-Objekte umzuwandeln. Für einen
Mobile.MSL.Table
etwa , der Längenangaben enthält, könnten aus einer Length-Spalte zwei Spalten werden, eine für den Wert und die andere für die Maßeinheit. Statt einer zweiten Spalte käme auch in Frage, die Maßeinheit in den Spaltentitel aufzunehmen, um Redundanz zu vermeiden. Soll jedoch
MobileExtricateTable
genutzt werden, so könnte die Length-Spalte auch bereits Java-seitig in zwei Spalten umgewandelt (in eine RealNumber und eine Text-Spalte) und nach der Konvertierung in die Austauschrepräsentation extriziert werden.
Um an die Daten zu gelangen, die in der Avenue-Repräsentation eines MSL-Typs enthalten sind, muß zunächst mit
{aMSLType}.get(1)
das zweite Listenelement extrahiert werden. Danach kann je nach MSL-Typ direkt auf einen Avenue-Typ zugegriffen werden (etwa bei Mobile.MSLPoint auf Point) oder mittels weiterer get() auf tiefer verschachtelte Inhalte (bei einer Matrix zunächst auf die UntypedMatrix, dann auf deren Zeilen, dann auf die einzelnen Avenue-Repräsentationen der MSL-Typen in den Zeilen und letztlich auf deren Inhalte.
Dieser Overhead ist aber nicht immer erwünscht oder nötig (etwa bei RealNumber, Boolean und Text, die eine unmittelbare Entsprechung in Number, Boolean und String haben). Ferner muß das genannte zusätzliche get() ausgeführt werden. Um overheadfreie, im allgemeinen jedoch mit Informationsverlust verbundene Avenue-Typen zu erhalten, können die vom Avenue-Script MobileReadAll in der Parameterliste erhaltenen MSL-Objekte in Avenue-Repräsentation mittels des AvScripts MobileExtricate... vereinfacht werden.
Im folgenden Programmfragment aus der Auswertungsmethode
StreetLength
(siehe Anhang für den Quellcode sowie Abb. 34, S. 131 für eine Übersicht) ist die Benutzung der Extrizierung bzw. Intrizierung fett dargestellt (Zeilen 3 und 8), die übrigen Zeilen geben die Konvertierung aus der bzw. in die Austauschrepräsentation wieder (Zeilen 1 und 2 bzw. 9 und 10).
Die Zeilennummern sind nicht Teil des Programmfragments.
(1) ParameterList = av.Run("MobileReadAll", SELF)
(2) streetName = ParametersList.get("streetName")
(3) streetNameAvD = av.Run("MobileExtricateText", streetName)
(4) '''''''''''''''''''''''''''''''''''''''''''''''''
(5) ' hier folgen Berechnungen, die auf streetNameAvR
(6) ' beruhen und zu streetLengthAvD führen
(7) '''''''''''''''''''''''''''''''''''''''''''''''''
(8) `für Length gibt es kein MobileIntricate...
(9) streetLength = {"Length", streetLengthAvD, "m"}
(10) ReturnParameterList.Make(1)
(11) ReturnParameterList.add("streetLength",streetLength)
(12) av.Run("MobileWriteAll", ReturnParameterList)

[19] engl. extricate = herauswinden; lat. extrico = herauswickeln
engl. intricate = verwickelt, kompliziert