Discussion :

[camboui]

Je voudrais sélectionner les x premiers éléments.
Un for-each les prend tous. Comment limiter aux 10 premiers par exemple?
J'imagine un truc du genre

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

<xsl:for-each select="item and position(item)<10">

Mais je sais pas...
Merci.

[camboui]

Ou plutôt comme ceci:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

<xsl:for-each select="item[position() &lt; 10]>"

[GrandFather]

Ou plutôt comme ceci:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

<xsl:for-each select="item[position() &lt; 10]>"

Ben voui, c'est bien cela...

[camboui]

Oui, en effet, mais...

Voici mon code exact

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

<xsl:for-each select="list/item[position() &lt; 10]">

Et ici, il m'en donne plus que 5. S'il y a par exemple 30 éléments "list" avec pour chacun un seul élément "item", il me sort tous les "item" (puisque qu'ils sont tous en position()=1 par rapport à leur parent direct qui est "list").

Et là, je sèche...

Merci

[GrandFather]

Puisque l'axe par défaut child ne convient pas, il faut utiliser l'axe descendant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

<xsl:for-each select="descendant::item[position() &lt; 10]">

[Erwy]

les parentheses c'est pas mal quand on n'a des probleme avec les priorités d'execution sur xpath

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

list/item[position() < 10]

selectionne les 9 premier fils de tous les list

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

(list/item)[position() < 10]

Selectionne les 9 premiers items qui sont fils de list

grandfather: tsss,tsss

[GrandFather]

les parentheses c'est pas mal quand on n'a des probleme avec les priorités d'execution sur xpath

Ouais, sauf que c'est à utiliser avec précaution, surtout quand on utilise des axes inverses et des prédicats positionnels.

Par exemple, soit le XML suivant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
<?xml version="1.0" encoding="UTF-8"?>
<test>
	<element>aaaa</element>
	<element>bbbb</element>
	<element>cccc</element>
	<element>dddd</element>		
	<fin/>	
</test>

L'expression XPath suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

/test/fin/preceding::*[position() < 3]

sélectionnera les noeuds suivants :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
<element>cccc</element>
<element>dddd</element>

Tandis que cette expression :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

(/test/fin/preceding::*)[position() < 3]

sélectionnera ceux-là :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
<element>aaaa</element>
<element>bbbb</element>

La raison en est que pour la première expression l'ordre du node-set renvoyé par preceding est préservé par le prédicat pour son évaluation, tandis que dans la deuxième le node-set est inversé pour suivre l'ordre du document. Pour éviter d'avoir à gérer ce genre de subtilité, il est préférable d'employer uniquement les parenthèses là où elles sont indispensables, comme avant des prédicats dans le cas d'union de node-sets, par exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

(/test/element[3]|/test/fin)[1]

[Erwy]

les parentheses c'est pas mal quand on n'a des probleme avec les priorités d'execution sur xpath

Ouais, sauf que c'est à utiliser avec précaution, surtout quand on utilise des axes inverses et des prédicats positionnels.

Ce qui n'est pas le cas ici

Puis si tu en viens a ce genre de chose je te rappelle que suivant les processeur, certains resultats d'axes change de sens et les unions ont le meme effet sur les positions finales des node-set que des parenthese (ce n'est pas un concat de noeud) alors le probleme des parenthese ca devient franchement secondaire la
Ne pas confondre precaution et empechement autrement on n'utiliserais plus un paquet de fonctionnalité xslt et xpath (qui ont parfois des propriétés annexes complexes)

[GrandFather]

Puis si tu en viens a ce genre de chose je te rappelle que suivant les processeur, certains resultats d'axes change de sens et les unions ont le meme effet sur les positions finales des node-set que des parenthese (ce n'est pas un concat de noeud) alors le probleme des parenthese ca devient franchement secondaire la

J'en sais quelque chose... Je suis en train d'écrire une implémentation de XPath (en Python), et je peux te dire pour l'avoir épluchée que la spécification du W3C n'est pas toujours d'une clarté limpide. Chaque éditeur y a été de son interprétation, d'où les divergences relevées surtout sur l'ordonnancement des noeuds.

Ne pas confondre precaution et empechement autrement on n'utiliserais plus un paquet de fonctionnalité xslt et xpath (qui ont parfois des propriétés annexes complexes)

Il n'y en a pas tant que ça. Les seules disparités significatives que j'ai relevées jusqu'ici portaient sur les parenthèses, l'union, et les noeuds de type namespace. Savoir que des effets de bord existent sur certaines fonctionnalités n'empêche pas de les utiliser, mais on doit garder à l'esprit les problèmes de portabilité que peut représenter le fait qu'ils peuvent différer d'une implémentation à une autre.

[Erwy]

J'en sais quelque chose... Je suis en train d'écrire une implémentation de XPath (en Python), et je peux te dire pour l'avoir épluchée que la spécification du W3C n'est pas toujours d'une clarté limpide. Chaque éditeur y a été de son interprétation, d'où les divergences relevées surtout sur l'ordonnancement des noeuds.

celui auquel je pense n'a pas cette excuse
Pour les parentheses et union cette partie n'est pas si absconse que ca je trouve(surtout avec une trad )
http://www.w3.org/TR/xpath#node-sets

The Predicate filters the node-set with respect to the child axis.

Par contre je n'arrive pas a mettre la main sur la gestion des parentheses:
Ainsi sur xmlspy il est obligatoire de toujours placer la premier parenthese au tout debut de l'expression

ainsi

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

((/A/B)[2]/C)[1]

est valide

mais pas

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

(/A/B)[2]/(C[1])

Ce qui n'est pas aberrant en soi mais j'aurais bien aimé une description et une explication

[GrandFather]

Pour les parentheses et union cette partie n'est pas si absconse que ca je trouve(surtout avec une trad )
http://www.w3.org/TR/xpath#node-sets

The Predicate filters the node-set with respect to the child axis.

Ce n'est pas si abscons effectivement quand on se rend compte que cet axe implicite pour les prédicats est ce qui fait que preceding::*[3] et (preceding::*)[3] ne renvoient pas la même chose. Mais c'est au terme de souffrances épouvantables éprouvées lors de séance de déboguage.

Par contre je n'arrive pas a mettre la main sur la gestion des parentheses:
Ainsi sur xmlspy il est obligatoire de toujours placer la premier parenthese au tout debut de l'expression

ainsi

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

((/A/B)[2]/C)[1]

est valide

mais pas

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

(/A/B)[2]/(C[1])

Ce qui n'est pas aberrant en soi mais j'aurais bien aimé une description et une explication

Ca se justifie par les règles de production du langage :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
[18]    UnionExpr    ::=    PathExpr  
          | UnionExpr '|' PathExpr  
[19]    PathExpr    ::=    LocationPath  
          | FilterExpr  
          | FilterExpr '/' RelativeLocationPath  
          | FilterExpr '//' RelativeLocationPath  
[20]    FilterExpr    ::=    PrimaryExpr  
          | FilterExpr Predicate 
[15]    PrimaryExpr    ::=    VariableReference  
          | '(' Expr ')'  
          | Literal  
          | Number  
          | FunctionCall

Ton expression (/A/B)[2]/(C[1]) matche la règle PathExpr. Si on la décompose, on a une FilterExpr - (/A/B)[2] - suivi du séparateur '/' et on devrait avoir en principe après un RelativeLocationPath ; or, (C[1]) est une PrimaryExpr, pas un RelativeLocationPath. C'est pour cela que l'expression est rejetée.

[Erwy]

Ce n'est pas si abscons effectivement quand on se rend compte que cet axe implicite pour les prédicats est ce qui fait que preceding::*[3] et (preceding::*)[3] ne renvoient pas la même chose. Mais c'est au terme de souffrances épouvantables éprouvées lors de séance de déboguage.

En meme temps c'est dans node-set() l'explication que je t'ai mise (mais c'est vrai que la traduction que j'ai aide bien)

Bon merci pour les parentheses je ne regarde pas assez cette p***n de grammaire

[camboui]

Ne vous battez pas, ne vous battez pas...
Vous avez résolu mon problème. J'ai même eu un autre qui marche aussi très bien... grâce aux parenthèses 8)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

<xsl:for-each select="(item[@type])[position() &lt;= 10]">

[camboui]

Et j'oubliais...
Merci!