Entwurf von hierachischen Tag-Strukturen

Hallo, Markus (B) und ich und andere, vorallem aber Markus g, haben in diversen Themen über die richtige Art zu taggen und wie man das weiter entwickeln könnte, diskutiert. Schließlich haben Markus und ich darüber sinniert, ob hierachische Tag-Strukturen vielleicht nützlich wären um den syntaktischen, aber was in meinen Augen noch schlimmer ist, den Semantischen Wildwuchs von Tags ein wenig einzudämmen. Um nun aber nich in jeder Diskussion, die sich mit Tagging beschäftigt wieder und wieder das Thema neu anzuschneiden u(und die anderen zu nerven), habe ich dieses Thema aufgemacht. Versteht das aber nicht als eine Privatveranstaltung sondern, wenn ihr Lust habt, diskutiert mit. Worum geht es: TAGs (im folgenden Objekt-Eigenschaften oder Eigenschaften) sollen durch eine hierachische Struktur erweitert werden - zuerst als “Agreement” und wenn die Methode bei den allermeisten Objekt-Eigenschaften funktioniert auch als Grundlage für die Strukturierung der OSM-Datenstukturen. Der Vorschlag sieht folgendermaßen aus: Eine Objekteigenschaft eines OSM-Objekts (Orte, Wege?, Flächen, OSM-Relationen) muss unter Umständen näher spezifiziert werden, bzw. ist von ihrer Natur her strukturiert. z.B. die Eigenschaft maxspeed = : Diese Eigenschaft kann oft für ein bestimmtes Wegstück definiert werden (normale Geschwindigkeitsbeschränkung). Was nun aber wenn die Geschwindigkeitsbeschränkungen für bestimmte Fahrzeuge eingeschränkt ist. Der Wert der Eigenschaft muss für einen Fahrtzeugtyp spezifiziert werden. Außerdem wäre es schön zu wissen, in welcher Maßeinheit (z.b. mph oder km/h) denn diese Maximalgeschwindigkeit angegeben ist? Unser Vorschlag ist eine Eigenschaft zu strukturieren bzw. zu spezifizieren, indem der Schlüssel der Eigenschaft durch einen Subschlüssel genauer bestimmt wird. Im Falle von maxspeed = : maxspeed: = maxspeed:unit = km/h Ein anderes Beispiel wäre (ohne jetzt auf konkrete Diskussionen diesbezüglich einwirken zu wollen) die Adresse eines Gebäudes, die naturgemäß strukturiert ist. Nun wisst ihr worum es geht. Diese Diskussion dient dazu, die genaue Syntax, Semantik, ect. und wo, wer, wann, wie Eigenschaften im allgemeinen und später dann konkrete Eigenschaften im speziellen strukturieren soll. =========== DER ENTWURF =========== Hier wird der aktuelle Stand der Diskussion gepflegt und der Entwurf für hierachische Eigenschaften dargestellt - Hinweise und Änderungsvorschläge einfach im Forum posten - (NEIN ich will das erst in ein Wiki stecken wenn es eine gewisse Qualität erreicht hat): Edit-Historie (inhaltliche Updates des Konzepts):

@Markus: Du hast den besseren Foren- und Wiki-Ãœberblick - kannst du bitte eine Linkliste posten, wo relevante Seiten zu diesem Thema sind, und kurz zu jedem Link schreiben was sie relevant macht? - ich werde derweil meinen ersten Vorschlag zu einer Struk

Zuerst einmal die Nomenklatur: Ein OSM-Objekt ist ein Element der Menge {Ort, Weg, Fläche}, oder der Menge der OSM-Relationen}. Jedem OSM-Objekt können Eigenschaften zugewiesen werden. Eine Eigenschaft besteht aus einem Schlüssel, der den Namen der Eigenschaft darstellt, und einem Wert, der die Ausprägung der Eigenschaft darstellt. Die Schreibweise für eine Eigenschaft ist: = <Schlüssel> = Soviel zu OSM wie es jetzt ist :slight_smile: Ohne Verletzung der oberen Basis-Struktur sollen folgende Syntaxelement semantisch realisiert werden - später irgendwann soll die Basisstruktur die semantischen Strukturelemente auch syntaktisch unterstützen. A) Hierachischer Schlüssel: = :<SUBKEY_1>:<SUBKEY_2>:…:<SUBKEY_N> = <SOME_SUB_VALUE> (N sollte natürlich klein sein!) Semantik: der Hauptwert der Eigenschaft mit dem Schlüssel wird durch <SOME_SUB_VALUE> entweder: a) parametrisiert (bei Werten, die von Nebenbedingungen abhängig sind - z.B. maxspeed in Abhängigkeit von Fahrzeugen) b) aufgebaut (bei stukturierten Werten - z.b. Adresse) c) attributiert (bei Werten, bei denen der Wert alleine keine eindeutige Aussage hat - z.B. Aufnahme von Maßeinheiten) Im Fall a) dienen die Subkey-Kontruktionen als zusätzliche Parameter von denen ein Schlüsselwert abhängig ist Bei b) bilden die Subkey-Konstruktionen die Struktur des Wertes ab. Bei c) dienen die Subkey-Konstruktionen als Namen für Eigenschaften des Wertes. Abstecher zur Missing-Values-Diskussion ----------------------------------------------- Falls sich mein Konzept für “Missing Values” http://forum.openstreetmap.org/viewtopic.php?id=1233 durchsetzt, sollte in Fall a) eine Kennung wie z.b. “__DEPENDING” (anstatt zum Beispiel “__VARIABLE” für nicht näher spezifizierbare Schwankungen/Änderungen des Wertes) für den Hauptwert benutzt werden. Dann sollte für den Fall b) ein andere Kennung “__STRUCTURE” kennzeichnen, dass sich der Wert aus anderen Werten der untergeordneten Schlüssel zusammen setzt. Denn in beiden Fällen würde der Hauptwert “FEHLEN”. ------------------------------------------------ Die Methode ist mit dem aktuellen Tagging-Konzept vereinbar, weil die Hierachie nur semantisch aufgeprägt wird. Es könnte sich jedoch als lästig erweisen, sie per Hand sauber einzuhalten. Daher sollten Regeln der Hierachisierung von Tags zumindest entwickelt und bereitgestellt werden, falls Tagging-unterstützende Software diese Schemata übernehmen möchte. Dies wäre der 1. Entwurf für ein hierachisches Eigenschaften-Schema für OSM-Objekte MfG Mark

Hirarchische Schlüssel in der Form :<SUBKEY_1>:<SUBKEY_2>:…:<SUBKEY_N> = <SOME_SUB_VALUE> finde ich sehr sinnvoll. Zumal es ja auch schon an vielen Stellen in OSM so genutzt wird. Zum Beispiel addr:housenumber oder name:de Allerdings stellt sich mir da immernoch die Frage, wie ich ein maxspeed für Fahrzeuge über und unter 3,5t tagge.

Naja - es ist noch nichts spruchreich :slight_smile: Aber bei diesem Schema könnte man einen SUBKEY von maxspeed entsprechend Semantik a) einführen: maxspeed = __DEPENDING maxspeed:above_3.5t = <Geschwindigkeit in km/h> maxspeed:below_3.5t = <Geschwindigkeit in km/h> maxspeed:unit = km/h Im Moment wäre dass allerdings eher schlecht. :slight_smile: In deinem Fall würde ich ein paar Stunden Wiki und Forum durchsuchen. Dann würde ich darüber im Forum und Wiki jammern. Und paralell sowas wie: maxspeed = <Geschwindigket1 in km/h> maxspeed:above_3.5t = <Geschwindigkeit2 in km/h> maxspeed:below_3.5t = <Geschwindigkeit1 in km/h> auf eigene Faust taggen und eine FIX-ME-Eigenschaft (Tag) setzen in dem ich nochmal jammern würde :slight_smile: MfG Mark

Meiner meinung nach ist das maxspeed = __DEPENDED unnötig, wenn sich das hirarchische tagging durchsetzt. Wegen dem “above_3.5t” … da is ja nicht klar was die 3.5t ausdrücken … gehen wir mal davon aus es gäbe eine Begrenzung für Autos über 2m breite, und eine andere Begrenzung für Autos mit über 4m höhe. Ein “below_4m” wüde da nicht klar machen, ob höhe oder breite gemeint ist. Ich würde daher folgendes vorschlagen: maxspeed:weight<3.5 = <Geschwindigkeit in km/h> maxspeed:weight>3.5 = <Geschwindigkeit in km/h> maxspeed:unit = km/h weight:unit = t

dabei fällt mir grad auf, dass wir uns unbedingt einigen müssen, ob wir den wert vom ersten Key angeben, oder vom letzten Key … Bei addr:housenumber wird die Hausnummer angegeben. Bei name:de wird allerdings der name angegeben. Genauso wird bei maxspeed: der maxspeed angegeben, bei maxspeed:unit allerdings die unit.

@TEL0000 maxspeed:unit ist eine Atributisierung nach Semantik c) - hier muss der Wert angegeben werden, der zur Zusatzinformation gehört maxspeed: ist eine Parametrisierung nach Semantik a) - maxspeed wird durch Fahrzeugtyp parametrisiert, ab

Wozu denn überhaupt die verschiedenen Semantiken? Lässt sich nicht alles über eine semantik abbilden? Woher soll eine Software denn wissen, welche Semantik verwendet wurde?

Ich würde das ganze frei wählbar anlegen. Mir geht es hier nur um die Tag-Struktur, und nicht um die genaue Bezeichnung von schlüsseln. Und da fällt mir nix besseres ein, als einen > oder < operator zu benutzen, damit eine Software das auch versteht.

maxspeed:weight:unit = t würde ja nur auf das maxspeed-tag auswirkungen haben, während sich weight:unit auf alles tags, die weight enthalten, auswirkt.

Das wäre ein enormer Aufwand sich für alle Länder der Welt entsprechende Bezeichnungen für solche schlüssel auszudenken. Zumal bei “above_3.5t” nicht klar wird, dass es sich hier um eine rein deutsche Regelung handelt. Wobei : > <Subkey1_Value> universal einsetzbar wär.

Zu den Semantiken: ============= Es gibt mindestens 3 Aspekte von Schlüsseln, oder besser gesagt deren Werte, die einer Erweiterung bedürfen. a) Schlüsselwerte sollten in Abhängigkeit von Rahmenbedingungen gesetzt werden können (Parametrisierte Schlüsselwerte - Beispiel: Höchstgeschwindigkeit in Abhängigkeit von Fahrzeugtypen) b) Schlüsselwerte könnten strukturiert sein. Sie sollten daher aus unterschiedlichen Werten zusammensetzbar sein. (Strukturierte Schlüsselwerte - Beispiel: Adressen) c) Schlüsselwerte müssen manchmal näher beschrieben werden Eindeutigkeit herzustellen. (Attributisierte Schlüsselwerte - Beispiel: Maßeinheiten) Diese Semantiken sollte in einem (zu entwickelnden) Tagging-Schema abbildbar sein. Mein Vorschlag ist, alle 3 über dieselbe Syntax abzubilden (wenn möglich), UND dass sie zu dem momentanen Tagging-Schema kompatibel ist. Dein Vorschlag: : {>,<,<=,>=,==} <Subkey1_value> = erfordert eine Definition von Relationen (z.B. “<”), sowie eine Definition frei wählbare Werte für <Subkey1_value>, die wiederum mit Wertebereichen, Maßeinheiten ect versehen werden müssen. - Außerdem schlägst du vor, dass man für ein OSM-Objekt global Maßeinheiten oder Beschreibungen setzen kann, die sich dann auf Untergeordnete Eigenschaften auswirken. Dagegen sprechen meiner Ansicht nach ein paar Dinge: 1.) Wollen wir nicht für jedes OSM-Objekt die komplette Semantik, Definitionsbereiche, Maßeinheiten, ect. der in diesem Objekt benutzten Tags beim einzelnen Objekt hinterlegen, müssen wir (für die Renderer zb.) Regeln, Werte- und Defintionsbereiche als Metainformationen vorhalten. In diesem Fall können wir das ebensogut für eine (gegebenenfalls große Menge von) symbolischen untergeordneten Schlüssel einrichten. 2.) Ein solches Tagging-Schema ist nicht mit dem jetzigen kompatibel. Da wir die Bedeutungen und Regeln für jedes {OSM-Objektklasse;Eigenschaft}-Paar ohnehin extern für die Sofware vorhalten sollten (nur um den Programmierern die Arbeit zu ersparen, selbst das Schema bereit zu stellen) - wie es jetzt schon quasi das Wiki übernimmt :slight_smile: - könnten wir auch, wenn die Symbolischen Schlüssel Anzahlmäßig überhand nehmen einen räumlichen Namensraum für die Schlüssel definieren (so dass “below_3.5t” in einer Tagging-Unterstützenden Software nur für Straßen in Deutschland existiert). Aber ich gebe dir Recht, für die Semantik der Parametrisierung wäre deine Syntax angemessener… ich möchte jedoch versuchen, ein Schema zu finden, dass eine möglichst saubere Trennung zwischen Schlüssel und Wert gewährleistet. Die Trennlinie ist das “=”. Gerade wegen der Kompatibilität… :slight_smile: Wie können die Software die Semantiken unterscheiden: zuersteinmal schließen für denselben Hierachie-Zweig auf derselben Hierachiebene Semantik a) und Semantik b) gegenseitig aus. (per Def.) Semantik a) stellt parallel Alternativen des Wertes (in Abhängigkeit von bestimmten Bereichen) zur Verfügung, Semantik b) stellt EINEN Wert bereit, der sich aus anderen zusammen setzt. Ob die Hierachie-Ebene auf dem Hierachie-Zweig gerade Semantik a) oder b) folgt kann durch den “Wert” festgelegt werden, auf den sich diese bezieht. Der Wert wird als __DEPENDING und __STRUCTURE gekennzeichnet. Um die Attributisierung des Wertes von Semantik a) und b) zu trennen, muss man sich was ausdenken. Z.B. könnte man statt = {__DEPENDING | __STRUCTURE} und : = value (Semantik a) oder b)) für Semantik c) schreiben: ::<Atributisierender Schlüssel> oder irgendwas anderes. Was den Aufwand angeht - so muss man sie sich nicht ausdenken: sie sind bereits durch die Realität gegeben. :slight_smile: MfG Mark

Ich muss dir Recht geben, dass dein Tagging-Schema das einzige wär, was mit dem momentanen Schema 100% kompatibel wär. Was die Semantiken angeht verstehe ich allerdings immernoch nicht, wie man dem Renderer beibringen soll welchen Key er rendern soll, und welcher nur zur Unterordnung oder Beschreibung dient. Was wäre denn dies für eine Semantik?: waterway = river waterway:name:de = Oder waterway:name:pl = Odra boundary = administrative boundary:name:de = Deutschland - Polen boundary:name:pl = Niemcy - Polska Ich wüsste jetzt zwar nicht, warum man eine Grenze benennen soll, aber es soll ja auch nur ein Beispiel sein. zu meinem Vorschlag : {>,<,<=,>=,==} <Subkey1_value> = : Du meinst also die Values sollten immer hinter dem = stehen. Klingt logisch, und daher ein neuer Vorschlag: maxspeed[1]:weight = <3.5 maxspeed[1] = 130 maxspeed[2]:weight = >3.5 maxspeed[2] = 80 Ist wieder nur eine spontane Idee, aber vielleicht bringt es uns ja weiter…

Also zu deinem Beispiel: =============== waterway = river eine einfache Eigenschaft mit dem Wert “river” - gültig für Flächen und Wege(?) (waterway:name = __DEPENDING) - Attributierung des Wertes “river”, d.h. Zusatzinformation mit den Namen des Flusses. (Semantik c)) - der Wert von waterway:name ist abhängig von bestimmten Nebenbedindungen - der Sprache (Semantik a)) waterway:name:de = Oder waterway:name:pl = Odra - de und pl sind untergeordnete Schlüssel von “name” nach Semantik a), die den Namen in Abhängigkeit von der Sprache parametrisieren. Der Renderer muss ohnehin die meisten Schlüssel kennen, um sie zu rendern - er muss wissen, das “name” ein Name ist, der schön auszusehen hat, und “river” eine blaue Linie/Fläche ist. - Kennt er “name” weiß er, dass wenn “name” __DEPENDING gesetzt ist, er den Namen passend zu Zusatzinformationen aus den untergeordneten Schlüsseln . Würde dort __STRUCTURE stehen, würde er den Namen (hoffentlich nach einer Regel, ansonsten irgendwie) zusammensetzen. __STRUCTURE und __DEPENDING können als gegenseitig ausschließend betrachtet werden. Das einzige Problem ist halt noch wenn ne Attributierung zusätzlich vorhanden ist. Also Zum Beispiel eine Adresse adress = _STRUCT adress:Street = <Straßenname | oder coole noch nicht durchdachte Referenz auf den Namen der Straße> adress:number = adress:postal_code = <PLZ | oder coole noch nicht durchdachte Referenz auf PLZ des Ortes in dem die STraße liegt> //und dann: adress:advertise = yes “Darf Werbung zustellt werden” adress:advertise ist eine Attributierung von adress - kein Teil ihrer Struktur. Man könnte das durch eine andere Symbolik für den Renderer oder die Software klar machen: adress::advertise = yes Man beachte die “::”. Aber das ist noch so ein Gedanke, der noch nicht reif ist. Dies dient ohnehin dazu es Renderern einfacher zu machen, wenn sie nicht die von uns bereitgestellten Regeln zu jeder Eigenschaft voll eingearbeitet haben hüstel Wegen deines Vorschlages zum taggen von maxspeed: wieder ergeben sich diverse Schwierigkeiten. 1) maxspeed[1] und maxspeed[2] sind 2 Schlüssel, die die gleiche Art Information tragen. Sie sind zwar dem Namen nach anders, was formal die Eindeutigkeit wieder herstellt… naja irgendwas schmeckt mir da gehörig nicht - aber heute abend finde ich die "guten Gründe"™ nicht - werde das Gefühl nicht los, dass wir mit dieser Struktur sowohl Tagger als auch Software-Entwickler foltern, aber heute abend krieg ichs nicht auseinander dividiert. 2) Das Problem mit einer sauberen Definition von Relationen, denen eine saubere Defintion von Wertebereichen ect vorrangeht, kriegst du mit dieser Konstruktion auch nicht behoben. Du musst immernoch das “>”-Zeichen sauber “erklären” Eventuell könnte das mit den Subschlüsseln: weight:exact weight:above weight:below gemacht werden, aber das ist wieder sehr holperig… Naja. Ich denk da nochmal nach. MfG Mark

Ich hab hier schonmal sowas ähnliches geschrieben: http://wiki.openstreetmap.org/index.php/Proposed_features/Properties_for_Tags Vielleicht könnt ihr es euch ja mal ansehen und in eure Überlegungen einbeziehen. Gruß

Also ich finde die Ideen richtig gut! Dazu mal ein praktisches Anwendungsbeispiel: Leuchtfeuer An der Küste steht ein Leuchtturm. Oben auf dem Leuchtturm sitzt ein Leuchtfeuer. Es weist die Schiffe auf den direkt unterhalb liegende Hafen “Timbuktu” hin. Das Licht ist weiss. Damit die Bewohner an der Küste nicht gestört werden, leuchtet das Feuer nur zum Meer hin. Zum Hafen hin führt eine ausgebaggerte Fahrwasserrinne. Damit die Schiffe diese erkennen, hat das Leuchtfeuer einen grünen Sektor, genau über der Fahrwasserrinne. Vor der Küste gibt es noch eine Untiefe. Damit die Schiffe dieser ausweichen können, hat das Leuchtfeuer hier einen roten Sektor. Das weisse Licht leuchtet, da ungefiltert, weiter als das grüne, und das grüne weiter als das rote. Die **Sektoren **sind also wie folgt sichtbar: Gesamt-Sichtbarkeit: 270° - 100° Weiss: 270° - 320°, Tragweite 20 Seemeilen Rot: 320° - 340°, Tragweite 6 Seemeilen Weiss: 340° - 020°, Tragweite 20 Seemeilen Grün: 020° - 030°, Tragweite 8 Seemeilen Weiss: 030° - 100°, Tragweite 20 Seemeilen Wie würde das dargestellt? {{Tag|man_made|lighthouse}} {{Tag|seamark|light}} {{Tag|seamark:light:name|Hafen Timbuktu}} {{Tag|seamark:light:InternationalCodeNumber|12345.6}} … Es gibt Leuchtfeuer, die rundum strahlen, solche mit einem einzigen weissen Sektor, solche mit bis 10 Sektoren in unterschiedlichen Farben und Tragweiten. Gruss, Markus

Genauso gehts mir mit deimen _DEPENDING und _STRUCTURE … das gefällt mir irgendwie garnicht, ich kanns aber auch nicht erklähren…

Genau den selben Gedanken hatte ich heute morgen auch, und da ist mir dann auch gleich eingefallen, wie man so eine Zeitbeschränkung umsetzen könnte. Also erstmal noch ein vorschlag für die Geschwindigkeitsbeschränkung: maxspeed[1]:weight:below = 3.5 maxspeed[1] = 120 maxspeed[2]:weight:above = 3.5 maxspeed[2] = 80 Die Schlüssel aufzuteilen in mehrere Teile hab ich mir schon an mehreren Stellen gewünscht. Hier mal ein Beispiel für das taggen einer zeitlich eingeschränkten Geschwindigkeitsbegrenzung: maxspeed = 30 maxspeed:times:days:from = Mo maxspeed:times:days:to = Fr maxspeed:times:hours:from = 9 maxspeed:times:hours:to = 17 sollte es zusätzlich noch eine andere Geschwindigkeitsbegrenzung für einen anderen Tag geben könnte man das so machen: maxspeed:times[2]:day = Sa maxspeed:times[2]:hours:from = 8 maxspeed:times[2]:hours:to = 12 Die Schlüssel hab ich mir jetzt nur spontan ausgedacht. Aber auch hier sehe ich keine andere Lösung als den Schlüssel mit times[2] aufzuteilen.

Hab grad hier noch eine neue idee gehabt: http://forum.openstreetmap.org/viewtopic.php?id=1297 also quasi maxspeed:2:weight:above = 3.5 maxspeed:2 = 80 oder maxspeed:times:2:hours:from = 9 Das würde in die hirarchische Struktur passen, und die Zahl wär quasi ein variabler Schlüssel, der nur der Aufteilung dient…

Sorry für die vielen Posts, aber ich will hier nochmal auf Markus eingehen…

Meine Idee wär: man_made = lighthouse seamark = light seamark:light:name = Hafen Timbuktu seamark:light:InternationalCodeNumber = 12345.6 seamark:light:radius:from = 270 seamark:light:radius:to = 100 seamark:light:color:1 = white seamark:light:color:1:range = 20 seamark:light:color:1:radius:1:from = 270 seamark:light:color:1:radius:1:to = 320 seamark:light:color:1:radius:2:from = 340 seamark:light:color:1:radius:2:to = 020 seamark:light:color:1:radius:3:from = 030 seamark:light:color:1:radius:3:to = 100 seamark:light:color:2 = red seamark:light:color:2:range = 6 seamark:light:color:2:radius:from = 320 seamark:light:color:2:radius:to = 340 seamark:light:color:3 = green seamark:light:color:3:range = 8 seamark:light:color:3:radius:from = 020 seamark:light:color:3:radius:to = 030 Zugegebenermaßen ein sehr kompliziertes Beispiel, aber dennoch mit dem Schema umsetzbar… (auch hier die tags nur spontan erfunden) Edit: hatte die Tragweite (von mir als “range” bezeichnet) vergessen…

Das klingt gut. Von der inneren Logik sind die Feuer nach Sektoren geordnet: seamark:light:name = Hafen Timbuktu seamark:light:sector:1:angle:from = 270 seamark:light:sector:1:angle:to = 320 seamark:light:sector:1:color = white seamark:light:sector:1:range = 20 seamark:light:sector:2:angle:from = 320 seamark:light:sector:2:angle:to = 340 seamark:light:sector:2:color = green seamark:light:sector:2:range = 8 … Es gibt Regeln: Leuchtfeuer:Sektoren = 1:n sector = {angle:from, angle:to, color, range} color = {white|green|red|yellow} Wie könnte man das Ganze als **Schema **definieren? Gruss, Markus

@Markus: Das ganze in Sectoren einzuteilen funktioniert natürlich auch. Du hast bei dir aber einen Fehler drin. Es müsste natürlich “seamark:light:sector:2:color = green” heißen. (ohne “from”) :wink: Deine Frage verstehe ich nicht ganz. Ein Schema has

schon, aber das muss sowohl für Osmarender und Mapnik (für die Ausgabe), als auch für JOSM (Validator bei der Eingabe) noch als “Regel” formuliert werden, damit sie es “verstehen”. Dafür gibts z.B. bei JOSM eine xml-Datei, in der s formuliert sind: http://josm.openstreetmap.de/svn/trunk/styles/standard/elemstyles.xml Ich habe aber keine Ahnung, wie man in xlm hierarchische Mehrfach-Attribute beschreibt. Gruss, Markus