boubou a écrit 1384 commentaires

Tu as parfaitement raison, mais justement, on quitte très vite le débat technique. Par exemple, il est classique d'affirmer qu'on développe plus vite en Java qu'en C++. J'ai pu le vérifier moi-même. Mais où est la vérification scientifique de ce fait ? Et quand bien même, pourquoi cet argument devrait-il être décisif ? En gros, on a plein d'arguments, plus ou moins fondés, mais on reste devant un problème de décision multi-critères, domaine de recherche à part entière...

Donc, tu n'as toujours pas compris. La remarque de Master-dik n'est pas pertinente car le principe de "least astonishement" est justement que des attributs sans préfixe soient traités comme ils le sont quand on ne tient pas compte des namespaces. Le truc, c'est que comme personne ne lit les normes, personne n'avait compris avant les namespaces que les attributs étaient dans des espaces de non spécifiques, donc tout le monde est étonné par un truc logique. Si tu veux légitimement dire que les concepteurs de 1.0 n'ont pas vu plus loin que le bout de leur nez, commence par lire la norme et par la comprendre.

Tu devrais lire la spec (http://www.w3.org/TR/REC-xml(...)), en particulier les "design goals". Le but est qu'un être humain soit capable de LIRE un document XML (point 4). Il est explicitement indiqué que la consision (terseness) n'a que très peu d'importance (point 10). A aucun endroit il est indiqué que le but est de faciliter l'ECRITURE d'XML à la main. Le fait que XHTML ainsi que des dizaines d'autres dialectes XML soient justement du XML n'a aucun rapport avec le fait que XML soit destiné à être écrit à la main...

En plus, sans l'avoir lu j'avais deviné son contenu

Trop puissant tu es. Surtout quand on voit la qualité de ton intuition.

La même chose, avec d'autres mots : tu te fous de notre gueulle ou t'as juste de grosses chevilles (c'est laid, les grosses chevilles) ?

Toujours la même chose, mais en plus clair : tu te rends compte que le point numéro 3 de la critique c'est exactement le contraire de ce que tu racontes dans ton super commentaire top intuitif ? Ce que critique l'auteur, c'est justement que XSLT permet de distribuer directement du XSL:FO, ce qui fait perdre la sémantique.

Dernière version : quel con je suis, tu n'as toujours par lu l'article.

Vivement le retour des XP...

Je te sens énervé là. Il faut dire que quand quelqu'un répond sans même avoir lu les liens que tu postes il y a de quoi. Sinon, pour surenchérir sur ton point 3 je trouve incroyable que frecillia8 nous sorte l'argument IE en avance sur les autres pour le traitement XSL, alors que l'avance en question était une implantation totalement foireuse de XSLT basé sur un parseur assez étrange...

Tu devrais lire http://www.w3.org/Style/CSS-vs-XSL(...) au lieu de dire des conneries. Plus je te lis plus j'ai l'impression que tu n'as rien compris à XSLT.

C'est intéressant, mais avec quand même un certain biais. Je m'explique : une grande partie de l'argumentation se focalise sur le fait que XSL est imbitable par rapport à un langage de programmation standard. Je pense qu'on touche ici à un problème intéressant. Personnellement je trouve que les langages fonctionnels comme XSL ou scheme sont beaucoup moins clairs que les langages impératifs. Le sommet est atteint à mon avis par OCaml que je trouve totalement incompréhensible (ça ne veut pas dire que je ne sais pas programmer en OCaml, ça veut juste dire que ça me prend beaucoup plus de temps, de réflexion et d'efforts qu'en Java, par exemple). Pourtant, je suis sûr que certains lecteurs de Linuxfr sont convaincu du contraire. Et dans un tel débat, aucun argument technique ne permet de trancher. Donc, effectivement, DOM+CSS c'est super (et d'une certaine manière plus puissant que XSLT+XSL:FO), mais à la limite, on s'en fout...

Si, si et à la fin tu obtiens une bouse immonde...

CSS ne permet pas de mettre en forme, il permet de réaliser une présentation, ce qui n'est pas la même chose (tu ne changes pas la structure du document XML).

Quant à ta deuxième solution, elle est peut être plus rapide, mais elle ne couvre que certains cas, manque singulièrement de souplesse et n'est pas modulaire du tout.

Et d'ailleurs, ce système avec des caches, de la compilation de feuilles de style, etc., on appelerait ça cocoon ? http://xml.apache.org/cocoon/index.html(...)

Suite...

Grâce à l'extension des namespaces, non seulement on a plusieurs collections de nom d'éléments, mais en plus, on peut placer les attributs dans d'autres collections de noms que celle correspondant à chaque élément.

Moralité, avant de critique n'importe comment, il est utile de savoir de quoi on parle, par exemple de lire et de comprendre les normes...

Sinon, aucun rapport : suis-je le seul à ne pas pouvoir poster de "gros" textes ? Je me demande si le fait d'être sur renater ou d'avoir un routeur CISCO peut poser des problèmes ???

J'ai bien l'impression que tu n'as pas bien compris les namespaces. Les namespaces ne sont pas une hiérachie de noms, mais des collections disjointes de noms qui s'ajoutent aux collections déjà présente en XML. Si tu avais compris ce principe, ça t'éviterait de critiquer quelque chose qui est logique. Parce que vois-tu, même sans l'ajout des namespaces, les attributs sont dans des collections de noms à part.Plus précisément, dans un document XML sans namespaces, tu as déjà une collection de noms correspondant aux éléments, puis une collection de noms pour chaque élément correspondant aux attributs (de l'élément). C'est pourquoi tu peux avoir deux attributs qui portent le même nom dans deux éléments différents, avec une interprétation différente pour chaque attribut. Les attributs ne sont donc jamais dans le même namespace que leur élément dans XML de base.


A suivre...

Ob ne va pas reprendre un milliard de fois cette discussion débile. PDF n'est pas ouvert au sens où tu n'as pas le droit d'ajouter des choses ou de contourner la spec. Par contre, si tu respectes la spec, tu as le droit d'implanter comme tu veux le standard. Donc, c'est disons "semi-ouvert".

Mais qu'est-ce que tu racontes ? css et XSL, ça n'a presque rien à voir, que ton "flux" XML soit "taillé sur mesure" ou pas.

DSSSL (http://www.jclark.com/dsssl/(...) ), mais bon :

1) c'est pour SGML
2) ça reste genre scheme (donc plein de () qui sont quand même plus lisible je trouve que XML, mais bon...)

Sinon, comme je le dis plus bas, XML n'a jamais été fait pour être écrit à la main, il faut donc utiliser un éditeur adapté...

Trop puissant, tu es le 96 et je suis le 97 !!!!!!!!!

Bon sinon, je suis d'accord et je dirais même plus qu'XML n'a jamais été conçu pour être écrit à la main...

Master-dik, je t'aime beaucoup quand tu fais des blagues lourdes, mais il y a des limites.

Il existe au moins deux langages très intéressants qui compilent pour la JVM, à savoir Python et Eiffel. Donc, bien sûr, le lien donné plus haut contient aussi des choses plus anecdotique, mais franchement entre VB sur .Net et Eiffel sur JVM, j'ai un petit faible pour la deuxième solution...

Sinon, effectivement la JVM a été pensée pour Java, mais la machine virtuelle .Net (CLR) a aussi été conçue avec certains biais. Par exemple le CLR a été conçu presque uniquement pour le JIT contrairement à la JVM. Sur le site http://www.citi.qut.edu.au/research/plas/projects/cp_files/Componen(...) il a d'ailleurs une comparaison assez claire des deux architectures. On constate par exemple que la vérification de code pour CLR demande nécessairement une partie runtime, ce qui n'est pas le cas pour la JVM (d'où une perte de performance pour le premier). Par contre CLR autorise le passage de paramètre par adresse pour les types fondamentaux, ce qui permet une implantation efficace des langages qui autorisent ce genre de construction, contrairement à la JVM. Un autre aspect est que l'interprétation (sans JIT) du code CLR est souvent plus lent que pour la JVM, toujours pour des raisons d'architecture.

Bref, CLR a été effectivement pensé pour supporter divers langages, mais en pratique il y a une seule différence majeure avec la JVM : la possibilité d'implanter efficacement le passage par référence des types fondamentaux. Franchement, on ne va pas en faire tout un fromage...

Depuis quand avoir un master en Informatique et en IA est une marque d'intelligence ou de compétence ?

Je suis prof en fac, tu vois, alors les diplômes...

D'autre part, dans ton post un peu ridicule, tu compares C# à Java. Franchement, les deux langages sont presques identiques, avec quelques features un peu plus complexes en C# (comme les structs en plus des objets). Donc, prétendre que C# est plus facile d'accès que Java, c'est du grand n'importe quoi. Je n'ai rien contre C# (qui contient même plein de choses intéressantes), mais c'est au moins aussi complexe que Java.

En cours de normalisation pour .net. Etant donné que la Apache Fundation est un acteur majeur du système des JCP et que les specs sont implantables en open source (avec en plus un financement de sun pour la certification), je pense que dire que .net est plus ouvert que java est du domaine du pur FUD.

Petite confusion. Il y a une JVM blackdown (http://www.blackdown.org(...) ) et une JVM IBM qui n'ont rien en commun, excepté qu'elles sont toutes deux (à ma connaissance) dérivées du code de Sun (j'en suis sûr pour celle de blackdown, moins pour celle d'IBM) et en ce sens ne constituent pas une alternative à la JVM de Sun. Par contre, il y a bien la JVM d'Intel qui est très avancée et Open Source (ORP, http://orp.sourceforge.net/(...) ).

Master-dik, tu es vraiment un génie. Je t'admire.

Non, c'est pas populaire parce que ça bouffe un maximum de ressources (surtout en mémoire).

Lisp c'est déjà fait, ça s'appelle XSLT. Ba oui, parce que franchement tant qu'à faire du récursif dans tout les sens, je préfère faire ça avec un langage adapté à la manipulation des données XML...

Ouaip, j'ai même une mach64 sur ma machine achetée en octobre 95...

+

Hein, quoi, plus de + ?

Pourquoi y'a plus les + ?

Ouin.

Oui, je sais, -