xml decid : Stratégies, marchés, affaires autour de XML.
[xml-decid] Re: XSLT Experiences Douloureuses ?
From: Laurent CAPRANI (caprani@altern.org)
Date: 06/08/2002 - 11:38
> -----Message d'origine-----
> Herve AGNOUX
> Envoyé : lundi 5 août 2002 12:16
>
> Le 29 Jul 2002 abella free a écrit :
> > Je souhaiterai savoir si quelqu'un peux m'informer sur des experiences
> > douloureuses (difficultes de programmation, de realisation ou de mise
> > en exploitation) rencontrees lors de l'utilisation d'XSLT.
>
> On dit souvent que XSLT peut transformer n'importe quel document XML
> en n'importe quel autre document XML. C'est vrai. Le seul ennui,
> c'est que "n'importe quel" ne signifie pas forcément "le document
> précis que l'on veut vraiment". Il y a quelques traitements
> difficiles à réaliser avec XSLT, comme le classement des
> informations, par exemple.
A la catégorie "traitements pénibles en XSLT", je verse la hiérarchisation
(ou groupage):
Passer de <P/><LI/><LI/><LI/><P/><LI/><LI/>
à <P/><UL><LI/><LI/><LI/></UL><P/><UL><LI/><LI/></UL>
suppose des contorsions pénibles.
Ici, c'est XPath qui est en faible car il ne maîtrise pas bien les
adjacences.
En règle générale, XSLT maîtrise mieux le passage d'une structuration forte
à une structuration faible que le contraire.
XSLT a été conçu pour le style (phase aval des traitements) et non pour la
génération (phase amont).
L'aspect saillant de cette orientation est la faiblesse de XSLT à
reconnaître des motifs (patterns) dans les contenus comme dans le balisage.
> Nous avons eu récemment quelques échanges à propos de la vitesse de
> traitement des fichiers XML. Je vous avais dit qu'à mon avis il était
> possible de recevoir et de tester les fichiers XML aussi vite que
> n'importe quelle autre format. Mais, sur les transformations XSLT, je
> n'essaierai même pas de me battre. Si vous avez des fichiers de
> plusieurs mega octets à transformer et que le temps est pour vous un
> paramètre important, XSLT est une mauvaise technologie.
Oui, XSLT n'est pas un outil de traitement du signal. Il se cantonne au
"périmètre sain" de XML, que je situe dans la petite centaine de Ko.
Notez que celà représente l'essentiel du traffic Internet et qu'au delà les
problèmes sont d'avantage des problèmes de transport que d'information.
Ajoutons que XSLT se répand dans les foyers à la faveur de IE6 (et Netscape
7). Les sites vont sans doute en tirer profit et la compétence XSLT va se
banaliser.
> Un cas typique est que le designer veut souvent mettre la première
> lettre d'un paragraphe en relief. C'est évidemment complètement
> inutile du point de vue de l'auteur. Et il ne viendrait à l'idée de
> personne de placer des balises pour repérer la première lettre d'un
> paragraphe. Par conséquent il est difficile de réaliser cela avec
> XSLT, alors que c'est une démarche extrêmement courante chez les
> designers.
Là, on atterrit dans la restitution (rendering), qui est le jardin de CSS.
CSS est censé intervenir à ce niveau, avec par exemple son sélecteur
<élément>:first-letter qui permet de créer une lettrine.
> Une autre expérience douloureuse est que XSLT est une technologie
> assez ardue. Il faut savoir utiliser le XSLT soi même, le XPath, tout
> connaître des subtilités du XML bien sûr, avec en plus probablement
> le domaine métier + le domaine designer ! Autant dire que c'est
> mission impossible, est la personne qui s'occupe d'écrire la
> transformation XSLT doit être avant tout une personne de dialogue.
XSLT pose en effet un problème de chevauchement des compétences. Si on place
de la cosmétique dans un XSLT plein de templates nommés, de keys et de XPath
alambiqués, le graphiste et le programmeur vont continuer à se marcher sur
les pieds.
Quelques astuces permettent de réduire cet inconvénient. Voir l'article
"Feuilles de styles sans style."[1]
Coté subtilités de XML, je mentionnerai le traitement des espaces non
significatives (et l'influence de la DTD), la fragmentation des contenus
textuels (en présence d'appels d'entités notamment).
Dernière douleur: les disparités entre les implantations. Le processeur
Sablotron, qui est intégré à Perl et PHP est sans doute le plus déviant du
lot. Chaque processeur a ses petites manies et ses petits bugs irritants.
-- Laurent CAPRANI
[1] http://xmlfr.org/documentations/articles/001214-0001
--
Devenez redacteur <XML>fr et contribuez au developpement
du xml francophone (http://xmlfr.org/infos/redacteurs) !
Liste de diffusion "xml-decid@xmlfr.org" (http://xmlfr.org).
Cette liste est a votre disposition pour discuter en francais de
tout sujet lie a XML.
Pour resilier votre abonnement, envoyez un message contenant la
commande "unsubscribe" a xml-decid-request@xmlfr.org
(mailto:xml-decid-request@xmlfr.org?Subject=unsubscribe)
Archive générée par hypermail 2.1.3 le 30/08/2002 - 19:52 UTC
webmaster@xmlfr.org
| 
