# xpath: in Kindelement zwei Attribut-Werte auslesen



## Gast2 (24. Jan 2012)

Hier habe ich das ganze von heute Vormittag noch mal als Kompinationsproblem:
(Nehmen wir an, das es um das erste Kindelement *name *geht.)



```
<xsl:value-of select=" Route:setTpoIdent($routeNode, name:(concat(@network, @line))) " />
oder
<xsl:value-of select=" Route:setTpoIdent($routeNode, name/(concat(@network, @line))) " />
oder
<xsl:value-of select=" Route:setTpoIdent($routeNode, name::(concat(@network, @line))) " />
oder
<xsl:value-of select=" Route:setTpoIdent($routeNode, name @(concat(@network, @line))) " />
oder
<xsl:value-of select=" Route:setTpoIdent($routeNode, /name/(concat(@network, @line))) " />
```

. . . geht alles nicht.

Mit for-each möchte ich _nicht _gerne arbeiten, weil die Performance eine große Rolle spielt. 
Ausserdem gibt es das Elemt "name" immer genau einmal.

Kann man den Pfad in eine Zeile schreiben?
Wenn ja wie?
Und wenn nein, kann man es so in zwei Zeilen bringen,
dass der Pfad zu *name *wechselt und man in der zweiten Zeile einfach mit concat weiterarbeiten kann?

Frank


----------



## SlaterB (24. Jan 2012)

> Hier habe ich das ganze von heute Vormittag noch mal als Kompinationsproblem:
da du es selber schon ansprichst und fast niemand verstehen wird: wieso keinen gemeinsamen Thread für alle deine Fragen?
allzu viele Antworter zu XSLT sehe ich hier eh nicht, ich selber werde neue Fragen schon bemerken 

auch diesmal glaube ich noch was gefunden zu haben, puh, aber nur nach Tests,
name außerhalb von concat ist Quark, es muss schon innerhalb bei jedem XPath mit dabei sein,

[c]name@network[/c] geht nicht, aber [c]name/@network[/c] dann,

-----

eine Alternative zu for-each kenne ich nicht, und so groß ist die Auswahl an Standard-Mitteln ja auch nicht
XSLT <xsl:for-each> Element

> Ausserdem gibt es das Elemt "name" immer genau einmal.

mit anderen Mitteln oder direkter Referenzierung hast du dann genauso Probleme/ Doppeldeutigkeit, 
das ist von for-each unabhängig,
wenn du auf Attribute einschränken kannst, geht das in allen Fällen

mit Geschwindigkeit würde ich persönlich bei XSLT nicht argumentieren, jedes value-of mag intern hunderte Methoden durchlaufen (ich weiß es aber nicht, BlackBox),
da auch eine Festplatte mit Datei beschrieben werden muss, besonders wenn noch PDF draus wird, kann man eh immer mit Sekunden Overhead rechnen, reine Berechnung sollten da eigentlich nicht auffallen, aber bei dir vielleicht anders,

wenn es wirklich um Zeit geht, dann vielleicht komplett ohne XSL-Transformierung die neue XML-Stufe von Hand in Java zusammenbauen, StringBuilder & Co.,
passt dann auch ein wenig zu deinen eingebettenen Java-Code,
bei komplexen XML + Transformationsregeln aber sicherlich nicht so leicht zu machen


----------



## Gast2 (25. Jan 2012)

Hi Slater!

Danke für Deine Antwort.
Ich freue mich, dass diese Zeile concat nun auch funktioniert. 

Übrigens parse ich eine http-bezogene xml direkt in die Klassen (Objekte).
Ich arbeite mit Saxon und der Geschwindigkeitsanstieg im Verhältnis zu anderen Parsern ist beträchtlich. (Aus 5 Sekunden mache 0,2 bis 0,3 Sekunden). 

Es sind allerding so um die 30 Klassenobjekte mit zahlreichen Bedingungen, in denen die Daten rein müssen. Das macht das Handling (xslt) leider sehr aufwendig.

Grüße nach Norden! Frank


----------

