Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Oui c'est bien pratique. Ce que je voulais dire c'est que je ne sais pas lire des fichiers en regardant, avec mes yeux, ma clé USB! Il faut de toute façon des outils.
Tout est affaire d'encodage. Comme XML est codé en texte, les outils les plus simples, les plus généralistes et, donc, les plus répandus suffisent pour des petits documents. Ces outils ont été développés avant la création de la notation.
Formulaires XForms sur tous navigateurs sans extension à installer (architecture XRX) : http://www.agencexml.com/xsltforms/
ce qui me fait penserEnvoyé par alain.couthures
Un outils très simple pour lire/modifier des XML, même d'assez gros volume , c'est un problème qui revient frequemment,fait par microsoft (je ne connais pas l'equivalent linux désolé): XML Notepad 2007
Pour continuer sur la "multi-utilisation".
Nous sommes à une époque où les vues "Business Intelligence" sont de plus en plus omniprésentes, mais où cela sort de plus en plus du domaine des BDD.
Les ensembles documentaires, voir le Web sont de plus en plus le domaine de recherche et la part des technologies XML y est prégnante pour deux raisons:
1) les technologies XML comme RDF y servent de marqueur
2) Le format XML permet l'interroperabilité des sources de données de ce format même si ce n'est pas le but originel.
On peut en effet en utilisant les mêmes outils croisé des données qui viennent d'un XHTML, d'un SVG, d'une extraction XML de BDD ou d'un Document Ooo ou office, alors que certains de ces formats (comme SVG) ne sont pas nativement prévu pour des utilisations de ce type.
Donc je suis désolé pour ceux qui haissent le Tout XML car même si je partage leur avis sur certaine utilisations peu appropriées (fichier INI, voir JSON pour des requêtes qui n'ont aucun but à être analysé ou stocké) , cette vision décisionnelle risque de ne pas ralentir ce mouvement dans l'avenir.
Bien sûr ! Tout ce qui est en XML, ou qui peut être facilement transformé en XML (c'est pour cela que j'ai écrit un convertisseur simple HTML vers XML bien formé), est analysable en tant que données.
S'il est vrai que XSLT rebute beaucoup de monde, notamment du fait de la récursivité (Michael Kay a même déclaré à XML Prague 2010 que la récursivité n'est pas à la portée de n'importe qui !), encore faudrait-il que l'on forme dessus !
Enfin, pourquoi je n'aime pas XQuery ? Parce qu'il n'est pas écrit en XML !!!
Formulaires XForms sur tous navigateurs sans extension à installer (architecture XRX) : http://www.agencexml.com/xsltforms/
En même temps c'est l'un des premiers trucs que j'ai appris en informatiques
Même si je dois reconnaitre en effet que c'est l'un des concepts qui pose pas mal de soucis dans le forum XSLT...
C'est malgré tout normal car la plus part des codeurs ont un background de php, C, Java et n'ont utilisé le récursif, au mieux, que dans des exercices théorique en cours ou pour certains algo.
En même temps pourquoi faire du récursif quand une approche itérative est suffisante et plus lisible?
Ca depend de la culture.
Quand j'ai commencé mes études on m'a dit qu'on avait demandé à différents types de personnes d'ecrire des algo pour solutionner des problèmes, si je me souviens bien, les mathématiciens avait une nette tendance à utiliser des formes récursives.
Une fois qu'on est habitué , même s'il est moins lisibles, le récursif est généralement plus puissant en terme de calculs surtout sur des algo complexes ou par rapport à des boucles imbriquées, c'est bien pourquoi XSLT est orienté fonctionnel comme type de langage (même s'il lui manque certains attributs pour être un langage fonctionnel à part entière).
La différence d'un point de vue technique c'est qu'on ne sait pas avec du récursif la capacité de la pile qui sera finalement utilisé avant la fin du calcul alors qu'en itératif, soit par la taille de l'objet à parser, soit par le nombre d'itération prévue, on sait la capacité maximum qui sera utilisé avant de commencer l'opération
La récursivité est plus incontournable en XSLT 1.0 qu'en XSLT 2.0.
Dans mon implémentation XForms en XSLT 1.0, j'ai du récemment remplacer une récursivité par une utilisation de l'extension node-set() suivie d'une simple boucle for-each parce que, pour un cas très complexe, certains moteurs, dont xalan, explosaient leur pile...
Tout ça, cela peut s'expliquer sous forme de bonnes pratiques XSLT.
Au demeurant, il n'y a pas que XSLT !
Formulaires XForms sur tous navigateurs sans extension à installer (architecture XRX) : http://www.agencexml.com/xsltforms/
Il y a d'autre langages normés pour manipuler de XML en XML?
XSLT est le seul langage XML recommandé pour transformer du XML en XML et sa future version avec streaming pourra remplacer d'autres approches comme STX.
Sinon, XForms "manipule" du XML pour de l'édition en formulaire. XProc permet d'enchainer des traitements XML en XML.
Quant à XQuery, il n'est pas en XML, mais il permet bien de manipuler du XML pour restituer autre chose. Beaucoup trouvent XQuery plus facile à apprendre que XSLT et ces deux langages sont maintenant mis en concurrence. Je miserais plutôt sur une convergence future entre les deux...
-Alain
Formulaires XForms sur tous navigateurs sans extension à installer (architecture XRX) : http://www.agencexml.com/xsltforms/
J'aurais dit plus ou moins le contraire: ne jamais utiliser XML pour des fichiers de moins de 10 ko!
L'avis publié ci-dessus est mien et ne reflète pas obligatoirement celui de mon entreprise.
Salut
Je suis d'accord, je crois d'ailleurs que tout le monde s'accorde sur l'utilité du XML mais, moins sur une édition manuelle (et non plus à lire même avec une très bonne structure). Je ne me rappelle plus exactement de la structure du fichier de conf (c'était le framework struts, c'est la seule chose dont je me souviens) mais elle était déjà bien lourde (donc la rendre structurellement plus complexe n'est pas forcément judicieux... sauf si --> voir plus loin ce que j'ai souligné). Quoiqu'il en soit, on écrit des données importantes dans ce genre de fichier et on a rien pour l'aide à la saisie ou la validation (enfin on utilisait rien serait le meilleur terme)..La virgule ne fait pas partie de la structure d'un XML, donc pour je ne sais quel raison tordue, on a inclu du traitement de chaine en plus du traitement XML et quand il y a un problème on accuse le XML
Si il y a une sépration sémantique des données, alors celle-ci doit être manifeste dans la structure même du XML,comme on le ferait dans une BDD et non pas dans de l'analyse de chaine à posteriori
Quand j'utilise Ooo, je clique sur un style et hop je vois directe mon document mis en forme, je clique sur centrer et hop ça centre le paragraphe, je change la couleur en choisissant dans la palette. Je n'ai jamais directement édité le XML
D'ailleurs, j'ai parlé de XDoclet pour s'affranchir des fichiers de conf J2EE (oui à l'époque il y avait encore le 2) en début de topic. Il s'agit ni plus ni moins qu'un utilitaire qui génère les fichiers XML.
pour info, aujourd'hui, je bosse avec (énormément) de XML tous les jours et je n'ai ni besoin d'en saisir ni besoin d'en lire
Yann
en lisant tout les avis , je pense que je vais faire une vérification d'un élément de mon projet ou j'ai utilisé du XML pour une configuration
Mon avatar ? Ce n'est rien, c'est juste la tête que je fais lorsque je vois un code complètement frappa dingue !...
Parce que tu n'as jamais eu à travailler sur des outils de GED basés sur OOo.Quand j'utilise Ooo, je clique sur un style et hop je vois directe mon document mis en forme, je clique sur centrer et hop ça centre le paragraphe, je change la couleur en choisissant dans la palette. Je n'ai jamais directement édité le XML
Je suis quand même assez étonné de retrouver en tête des récriminations contre XML son emploi abusif comme format de fichier de configuration, en lieu et place de fichiers INI ou .properties... Dès le début des années 2000, c'était déjà décrit dans beaucoup d'ouvrages de bonnes pratiques comme un anti-pattern, y compris par des auteurs convaincus de l'intérêt de XML. Si cet usage a perduré, il faut incriminer l'entêtement des concepteurs, pas le format.
Pour ce qui est de sa présence comme format de prédilection dans beaucoup de framework, il faut aussi se souvenir qu'une des grandes forces de XML est d'avoir, en imposant l'usage d'Unicode et de règles claires d'encodage des caractères, éradiqué les problèmes récurrents d'encodage de caractères non ASCII dans des flux destinés à transiter entre des plateformes différentes. Même si le balisage sémantique de XML n'apporte pas une plus-value déterminante dans tous les contextes, rien que cet aspect de l'encodage milite pour un usage élargi de XML.
FAQ XML
------------
« Le moyen le plus sûr de cacher aux autres les limites de son savoir est de ne jamais les dépasser »
Giacomo Leopardi
Tiens, c'est marrant, je retrouve, dans pas mal de commentaires, les questionnements sur les perfs et la verbosité que j'avais il y a quelque 7 ans. http://www.developpez.net/forums/d18...hange-donnees/
Entre temps, je n'ai jamais touché au XML.
Consultant / formateur Oracle indépendant
Certifié OCP 12c, 11g, 10g ; sécurité 11g
Ma dernière formation Oracle 19c publiée sur Linkedin : https://fr.linkedin.com/learning/oracle-19c-l-administration
Mais, entre temps, ORACLE s'est senti obligé d'attaquer Mark Logic sur le sujet des bases XML : http://www.marklogic.com/oracle-vs-marklogic.html
IBM et EMC sont aussi sur le créneau ! Est-ce un hasard ???
Formulaires XForms sur tous navigateurs sans extension à installer (architecture XRX) : http://www.agencexml.com/xsltforms/
Bonsoir
Je pense aussi qu'on a fait tout et n'importe quoi en xml
mais cela n'enlève rien des qualités de XML pas plus que ses inconvénients.
dans une autre vie j'utilisais dans mes application TCL celui-ci à l'avantage d'être très facile à intégré dans son application.
et du coup les fichiers de conf sont structurés facile à écrire et programmable (le fichier de conf peux lui-même calculer des valeur à mettre dans les paramètres)
les mix de format comme le fichier de conf d'apache (mélange de xml et de ini) est pour moi une catastrophe
ce n'est ni lisible ni facile à analyse
je fais un usage intensif de XML je l'utilise même là où il n'a habituellement pas lieu d'être.
je manipule énormément de structures de données et de formats d'échange.
très souvent je produit une représentation sxd de la structure du du format même si le format n'est pas XML. cela permet d'avoir une représentation abstraite facilement exploitable.
intellectuellement je préférerait une représentation UML. mais même avec les normes d'échanges de modèle UML on n'obtient pas de représentation complète d'une structure de donnée complexe.
on a souvent un tas de classe reliées entre elle mais ce n'est pas aussi lisible que xsd.
il y a tout de même des chose que je n'aime pas
il est plutôt difficile de représenter certaine chose.
par exemple j'ai un format XML standard et je veux luis ajouter des éléments non standard mais je veux aussi que les application qui connaissent ce standard puissent continuer à le reconnaître.
pas de pb pour ça il y a les namespaces
définir le xsd pour ces éléments est lui aussi facile à écrire.
si je veux définir dans ce namespace un attribut qui sera porté par les éléments du xml standard ça ce complique.
et si je veux qu'un seul élément bien particulier le porte le XSD n'est plus du tout vident à définir
une autre chose qui me gêne c'est que le W3C défini un DOM XML générique
mais jamais un DOM spécifique à des type de doc XML bien particulier.
pour prendre un exemple simple : XHML
j'ai un Objet du dom par exemple Table
si je veux lui créer un fils il faut n passer par la création d'un élément dans le document puis l'attacher au fils
Or Table ne peut avoir que très peut de fils différents un commentaire thead tbody ou tfoot.
le mode de fonctionnement du dom est parfait lorsque on reste au niveau du métalangage qu'est xml mais lorsque on est dans XHTML pourquoi ne pas avoir définit des méthode plus approprié
sur mon objet table je pourrait avoir les méthodes
addComment, addTBody, addTHead, addTFoot
cela faciliterait grandement les manipulation des DOM spécifique et serait bien moins producteur d'erreur.
enfin je suis déçu des outils. avec l'arrivée de XML on voyait enfin une certaine approche uniforme. et du coup l'espoir de voir des outils efficace, et riche.
XML à beau être human readable un bon outil c'est tout de même mieux.
et là hélas. le plus souvent cela consiste en un éditeur de texte avec un arbres à la windows associé.
les rare outils graphique son des plus fermés ne couvre de façon efficace qu'une toute petite partie des domaines. bref à moins d'en avoir 4 ou 5 ...
A+JYT
Je ne connais que l'aspect théorique des choses,Grandfather connait mieux la question que moi mais en connaissant le format XML OOo (au moins en partie), la structure de ton XML struts et du XSLT, il serait possible,et pas forcemment complexe, d'ajouter à OOo une option éditeur de config struts .Quoiqu'il en soit, on écrit des données importantes dans ce genre de fichier et on a rien pour l'aide à la saisie ou la validation (enfin on utilisait rien serait le meilleur terme)..
[..]
Quand j'utilise Ooo, je clique sur un style et hop je vois directe mon document mis en forme, je clique sur centrer et hop ça centre le paragraphe, je change la couleur en choisissant dans la palette. Je n'ai jamais directement édité le XML
Et c'est vrai pour un grand nombre de fichier XML à structure simple....
Mais pour ça faut avoir quelqu'un capable de coller son nez dans le fichier XML sans zoli interface e de mettre les mains dans le cambouis du XSLT.
De ce point de vue,le XSLT, bien qu'en théorie langage de haut niveau, me semble de + en + utilisé de manière "invisible", un peu comme certains langage de bas niveau dont tout le monde utilise des routines ou des composants sans le savoir...
Cela me semble aussi vrai pour le XML en général, certes ils est de plus en plus "voyant" mais j'ai parfois l'impression que cela ne reste que la partie immergé de l'iceberg, c'est juste que l'iceberg grossi....
Salut
En fait dans le fond, je suis d'accord avec tout ce que tu dis. C'est dommage que le titre du débat ait été changé (ouais, ça commence à être énervant ce genre de choses).
XML, c'est très bien mais, ce n'est pas utilisable par tous le monde. XML, c'est très bien pour persister des données. De mon point de vue, éditer un fichier XML à la main, c'est comme si je demandais à des utilisateurs d'une appli de gestion de directement modifier une base de donnée à coup de SQL. Après, il faut bien entendu que des gens mettent le nez dedans, ce n'est pas magique.
Bon en fait je t'ai juste paraphrasé donc je suis complètement d'accord
Enfin bon, avec les bonnes techno on peut transformer du XML vers du XML sans lire de XML, sans utiliser XSLT(je ne crache pas sur XSLT, c'est juste pour préciser qu'il y a des alternatives
à savoir EMF (Framework de modélisation sous Eclipse, partie immergé de l'iceberg) + persistances XML (ou XMI qui est aussi du XML) + transformation de modèle (ATL ou Java))
@sekaijin: regarde EMF, justement
yann
cela fait plus de 20 ans que je fais de l'informatique.... Et depuis 20 ans on convulse de la meme manière...
Une nouvelle technologie arrive pour soi disant rendre plus simple la résolution des problemes qu'on a
Au début c'est merveilleux et on utilise à fond la technologie jusqu'au jours ou on génère de nouveaux problemes
puis
Une nouvelle technologie arrive pour soi disant rendre plus simple la résolution des problemes qu'on a ....
Le plus dingue est que si on essayait d'etre plus simple et KISS (Keep It Simple and Smart) ... On éviterait bp de pertes d'énergie...
En attendant les éditeurs nous vendent des "révolutions" chaque année .... Et se retrouve dans du vendor locking à donf... et on ne progresse pas sur les algos et les méthodes réellement ...
A ma connaissance il y'a qu'un monde qui a su éviter cet éccueil... SAP . SAP est à la fois uptodate techniquement et à la fois trés conservateur ....
Pour finir
XML est un bon format si on l'utilise pour ses qualités. Si EDI n'avait été aussi indigeste.... La preuve : en quelques jours sur w3schools et developpez.com vous apprenez les bases XML/XSD/XSL qui vous permettent de régler 99% des besoins.... Pas de bol c'est toujours à cause de ce 1% restant qu'on se retrouve avec des allumés qui disent que ce qu'on utilise n'est pas bon.... Ce 1% qui avec un peu de bon sens et une bonne analyse dans la pluspart des cas pourraient etre éviter ...
Ouais, euh... Rajoute quand même DOM et SAX, pour 99% des besoins. XSD c'est surtout quand on est coincé avec de l'existant, je pense.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager