| Gabriel Dos Reis wrote: | > Olivier Azeau writes: | > [...] | > | >> A quoi sert "(;)", quelle information cela apporte-t-il | > (machine + | > | >> humain)? Si cela denote la semantique d'un complexe pour eviter | > | >> d'appeler un chat un chat (i.e. prefixer par Complex), | > | > Mais l'on recherche justement la manière d'appeler un chat. Selon | > | > le type d'application, on peut utiliser (admettons que l'on veuille | > | > fixer un membre m à j) : | > | > m = #c(0 1) ;; pour reprendre la notation à CL | > | > ou : | > | > Member m ::= Complex 0 1 | > | > ou : | > | > <member name="m"> | > | > <complex real="0" imag="1"/> | > | > </member> | > | > | > | | Mais le principal avantage du XML c'est que si tu trouves que la | > 1ère | > | forme est plus lisible (question de goût), tu écris qqe chose comme ça | > | : | > | | <xsl:template match="//member"> | > | <xsl:value-of select="@name"/> = <xsl:apply-templates/> | > | </xsl:template> | > | <xsl:template match="//complex"> | > | #c(<xsl:value-of select="@real"/> <xsl:value-of select="@imag"/>) | > | </xsl:template> | > C'était lisible, donc on met plus de bruit, c'est ça ? | > | Et tes données ne s'afficheront pas en XML mais avec ta notation | > préférée. | > je crois que ton newsreader te joue des tours sur le débat en cours. | > La question n'est pas de faire avaler un format arbitraire à XML. | > | | Il n'est pas question de faire avaler quoi que ce soit. | Qui a parlé de faire avaler un format arbitraire à XML ? pas moi en tt cas.
# Et tes données ne s'afficheront pas en XML mais avec ta notation # préférée.
| Je dis juste que si on critique la lisibilité de XML, il me semble | honnête de préciser que s'il existe un format facile à rendre lisible | en ASCII avec un effort minimum, c'est bien le XML.
il me semble honnête de préciser que s'il existe un format facile à rendre illisible en ASCII avec un effort minimum, c'est bien le XML>
je suis entièrement d'accord : il est déjà illisible.
| La réciproque est généralement fausse : transformer de l'ASCII en XML, | c'est galère.
Oh.
-- Gaby
Olivier Azeau <john@doe.com> writes:
| Gabriel Dos Reis wrote:
| > Olivier Azeau <john@doe.com> writes:
| > [...]
| > | >> A quoi sert "(;)", quelle information cela apporte-t-il
| > (machine +
| > | >> humain)? Si cela denote la semantique d'un complexe pour eviter
| > | >> d'appeler un chat un chat (i.e. prefixer par Complex),
| > | > Mais l'on recherche justement la manière d'appeler un chat. Selon
| > | > le type d'application, on peut utiliser (admettons que l'on veuille
| > | > fixer un membre m à j) :
| > | > m = #c(0 1) ;; pour reprendre la notation à CL
| > | > ou :
| > | > Member m ::= Complex 0 1
| > | > ou :
| > | > <member name="m">
| > | > <complex real="0" imag="1"/>
| > | > </member>
| > | >
| > | | Mais le principal avantage du XML c'est que si tu trouves que la
| > 1ère
| > | forme est plus lisible (question de goût), tu écris qqe chose comme ça
| > | :
| > | | <xsl:template match="//member">
| > | <xsl:value-of select="@name"/> = <xsl:apply-templates/>
| > | </xsl:template>
| > | <xsl:template match="//complex">
| > | #c(<xsl:value-of select="@real"/> <xsl:value-of select="@imag"/>)
| > | </xsl:template>
| > C'était lisible, donc on met plus de bruit, c'est ça ?
| > | Et tes données ne s'afficheront pas en XML mais avec ta notation
| > préférée.
| > je crois que ton newsreader te joue des tours sur le débat en cours.
| > La question n'est pas de faire avaler un format arbitraire à XML.
| >
|
| Il n'est pas question de faire avaler quoi que ce soit.
| Qui a parlé de faire avaler un format arbitraire à XML ? pas moi en tt cas.
# Et tes données ne s'afficheront pas en XML mais avec ta notation
# préférée.
| Je dis juste que si on critique la lisibilité de XML, il me semble
| honnête de préciser que s'il existe un format facile à rendre lisible
| en ASCII avec un effort minimum, c'est bien le XML.
| Gabriel Dos Reis wrote: | > Olivier Azeau writes: | > [...] | > | >> A quoi sert "(;)", quelle information cela apporte-t-il | > (machine + | > | >> humain)? Si cela denote la semantique d'un complexe pour eviter | > | >> d'appeler un chat un chat (i.e. prefixer par Complex), | > | > Mais l'on recherche justement la manière d'appeler un chat. Selon | > | > le type d'application, on peut utiliser (admettons que l'on veuille | > | > fixer un membre m à j) : | > | > m = #c(0 1) ;; pour reprendre la notation à CL | > | > ou : | > | > Member m ::= Complex 0 1 | > | > ou : | > | > <member name="m"> | > | > <complex real="0" imag="1"/> | > | > </member> | > | > | > | | Mais le principal avantage du XML c'est que si tu trouves que la | > 1ère | > | forme est plus lisible (question de goût), tu écris qqe chose comme ça | > | : | > | | <xsl:template match="//member"> | > | <xsl:value-of select="@name"/> = <xsl:apply-templates/> | > | </xsl:template> | > | <xsl:template match="//complex"> | > | #c(<xsl:value-of select="@real"/> <xsl:value-of select="@imag"/>) | > | </xsl:template> | > C'était lisible, donc on met plus de bruit, c'est ça ? | > | Et tes données ne s'afficheront pas en XML mais avec ta notation | > préférée. | > je crois que ton newsreader te joue des tours sur le débat en cours. | > La question n'est pas de faire avaler un format arbitraire à XML. | > | | Il n'est pas question de faire avaler quoi que ce soit. | Qui a parlé de faire avaler un format arbitraire à XML ? pas moi en tt cas.
# Et tes données ne s'afficheront pas en XML mais avec ta notation # préférée.
| Je dis juste que si on critique la lisibilité de XML, il me semble | honnête de préciser que s'il existe un format facile à rendre lisible | en ASCII avec un effort minimum, c'est bien le XML.
| La question de la simplicité de la transformation est donc réglée. ^^^^^^^^^^^^^^^^^
voulais-tu dire « lisibilité » ?
-- Gaby
drkm
Gabriel Dos Reis writes:
drkm writes:
| La question de la simplicité de la transformation est donc réglée. ^^^^^^^^^^^^^^^^^
voulais-tu dire « lisibilité » ?
Non. Ce n'était peut être pas clair. Je ne me souviens plus si Olivier à expliqué ce qu'était XSLT en l'introduisant dans la discussion.
Il s'agit d'un dialecte XML visant à représenter des règles de transformation d'arbres XML. Lorsque l'on applique, au moyen d'un processeur XSLT, un script XSLT constitué entre autre des deux modèles qu'Olivier a donné, à un document comme :
En fait, avec ses modèles, on obtient plutôt (pas testé, plutôt un peu au pif, mais ça devrait pas être loin) :
m
#c(01)
--drkm
Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
drkm <usenet.fclcxx@fgeorges.org> writes:
| La question de la simplicité de la transformation est donc réglée.
^^^^^^^^^^^^^^^^^
voulais-tu dire « lisibilité » ?
Non. Ce n'était peut être pas clair. Je ne me souviens plus si
Olivier à expliqué ce qu'était XSLT en l'introduisant dans la
discussion.
Il s'agit d'un dialecte XML visant à représenter des règles de
transformation d'arbres XML. Lorsque l'on applique, au moyen d'un
processeur XSLT, un script XSLT constitué entre autre des deux modèles
qu'Olivier a donné, à un document comme :
| La question de la simplicité de la transformation est donc réglée. ^^^^^^^^^^^^^^^^^
voulais-tu dire « lisibilité » ?
Non. Ce n'était peut être pas clair. Je ne me souviens plus si Olivier à expliqué ce qu'était XSLT en l'introduisant dans la discussion.
Il s'agit d'un dialecte XML visant à représenter des règles de transformation d'arbres XML. Lorsque l'on applique, au moyen d'un processeur XSLT, un script XSLT constitué entre autre des deux modèles qu'Olivier a donné, à un document comme :
En fait, avec ses modèles, on obtient plutôt (pas testé, plutôt un peu au pif, mais ça devrait pas être loin) :
m
#c(01)
--drkm
Olivier Azeau
Loïc Joly wrote:
Et pour info, parmi les formats gérés, XML (enrichi par une sémantique plus riche pour gérer les pointeurs) existe. Tout ça pour dire que ce qui compte pour la facilité à coder, ce n'est pas le format de sortie, mais uniquement la qualité de la bibliothèque de sérialisation.
Je ne crois pas avoir jamais dit qu'il fallait abandonner toute simplicité de code C++ de serialisation au profit de plus grandes possibilités sur le format d'échange.
Pour moi ce sont 2 problèmes orthogonaux et le meilleur choix ne peut résulter que d'un compromis. Je n'hésite pas à dire que manipuler du DOM en C++ c'est quelque chose qui apporte souvent plus de problèmes que de solutions. Mais, comme je l'ai déjà dit dans un autre message, avoir un format d'échange difficilement manipulable hors C++ est également une source de problèmes et dire qu'on n'a pas besoin d'XML à ce niveau là peut se révéler tout aussi dangereux que de négliger le code de sérialisation.
Loïc Joly wrote:
Et pour info, parmi les formats gérés, XML (enrichi par une sémantique
plus riche pour gérer les pointeurs) existe. Tout ça pour dire que ce
qui compte pour la facilité à coder, ce n'est pas le format de sortie,
mais uniquement la qualité de la bibliothèque de sérialisation.
Je ne crois pas avoir jamais dit qu'il fallait abandonner toute
simplicité de code C++ de serialisation au profit de plus grandes
possibilités sur le format d'échange.
Pour moi ce sont 2 problèmes orthogonaux et le meilleur choix ne peut
résulter que d'un compromis.
Je n'hésite pas à dire que manipuler du DOM en C++ c'est quelque chose
qui apporte souvent plus de problèmes que de solutions.
Mais, comme je l'ai déjà dit dans un autre message, avoir un format
d'échange difficilement manipulable hors C++ est également une source de
problèmes et dire qu'on n'a pas besoin d'XML à ce niveau là peut se
révéler tout aussi dangereux que de négliger le code de sérialisation.
Et pour info, parmi les formats gérés, XML (enrichi par une sémantique plus riche pour gérer les pointeurs) existe. Tout ça pour dire que ce qui compte pour la facilité à coder, ce n'est pas le format de sortie, mais uniquement la qualité de la bibliothèque de sérialisation.
Je ne crois pas avoir jamais dit qu'il fallait abandonner toute simplicité de code C++ de serialisation au profit de plus grandes possibilités sur le format d'échange.
Pour moi ce sont 2 problèmes orthogonaux et le meilleur choix ne peut résulter que d'un compromis. Je n'hésite pas à dire que manipuler du DOM en C++ c'est quelque chose qui apporte souvent plus de problèmes que de solutions. Mais, comme je l'ai déjà dit dans un autre message, avoir un format d'échange difficilement manipulable hors C++ est également une source de problèmes et dire qu'on n'a pas besoin d'XML à ce niveau là peut se révéler tout aussi dangereux que de négliger le code de sérialisation.
drkm
Olivier Azeau writes:
La question de la simplicité de la transformation est donc réglée.
Qu'est ce qui est réglé ?
La question de la simplicité de la transformation.
La simplicité du code C++ ou autre qu'il va falloir écrire pour visualiser des données complexes sérialisées en ASCII ? On peut tjr rêver...
PS : excuse moi de ne pas tester les fragments de codes qu'il m'arrive d'écrire ici ou là, surtout quand il s'agit de donner une idée générale. Ceci étant dit, au caratère espace près pour la séparation real/imag,
Ce qui n'est pas rien ...
Et modulo l'introduction de sauts à la ligne n'importe où dans la génération d'un format texte orienté-lignes.
Il y a des règles à respecter si tu veux sortir du plain text au moyen d'un script XSLT. Surtout au niveau des caractères blancs dont fait partie le retour à la ligne. Et tu es tombé dedans en voulant montrer la simplicité de la transformation du document XML vers le fichier plain text correspondant, orienté-lignes.
Ahem.
--drkm
Olivier Azeau <john@doe.com> writes:
La question de la simplicité de la transformation est donc réglée.
Qu'est ce qui est réglé ?
La question de la simplicité de la transformation.
La simplicité du code C++ ou autre qu'il va falloir écrire pour
visualiser des données complexes sérialisées en ASCII ?
On peut tjr rêver...
PS : excuse moi de ne pas tester les fragments de codes qu'il m'arrive
d'écrire ici ou là, surtout quand il s'agit de donner une idée générale.
Ceci étant dit, au caratère espace près pour la séparation real/imag,
Ce qui n'est pas rien ...
Et modulo l'introduction de sauts à la ligne n'importe où dans la
génération d'un format texte orienté-lignes.
Il y a des règles à respecter si tu veux sortir du plain text au
moyen d'un script XSLT. Surtout au niveau des caractères blancs dont
fait partie le retour à la ligne. Et tu es tombé dedans en voulant
montrer la simplicité de la transformation du document XML vers le
fichier plain text correspondant, orienté-lignes.
La question de la simplicité de la transformation est donc réglée.
Qu'est ce qui est réglé ?
La question de la simplicité de la transformation.
La simplicité du code C++ ou autre qu'il va falloir écrire pour visualiser des données complexes sérialisées en ASCII ? On peut tjr rêver...
PS : excuse moi de ne pas tester les fragments de codes qu'il m'arrive d'écrire ici ou là, surtout quand il s'agit de donner une idée générale. Ceci étant dit, au caratère espace près pour la séparation real/imag,
Ce qui n'est pas rien ...
Et modulo l'introduction de sauts à la ligne n'importe où dans la génération d'un format texte orienté-lignes.
Il y a des règles à respecter si tu veux sortir du plain text au moyen d'un script XSLT. Surtout au niveau des caractères blancs dont fait partie le retour à la ligne. Et tu es tombé dedans en voulant montrer la simplicité de la transformation du document XML vers le fichier plain text correspondant, orienté-lignes.
Ahem.
--drkm
drkm
Olivier Azeau writes:
Mais, comme je l'ai déjà dit dans un autre message, avoir un format d'échange difficilement manipulable hors C++
Tu parles d'ASCII ?!?
--drkm
Olivier Azeau <john@doe.com> writes:
Mais, comme je l'ai déjà dit dans un autre message, avoir un format
d'échange difficilement manipulable hors C++
Mais, comme je l'ai déjà dit dans un autre message, avoir un format d'échange difficilement manipulable hors C++
Tu parles d'ASCII ?!?
--drkm
Gabriel Dos Reis
drkm writes:
| Gabriel Dos Reis writes: | | > drkm writes: | | > | La question de la simplicité de la transformation est donc réglée. | > ^^^^^^^^^^^^^^^^^ | | > voulais-tu dire « lisibilité » ? | | Non. Ce n'était peut être pas clair. Je ne me souviens plus si | Olivier à expliqué ce qu'était XSLT en l'introduisant dans la | discussion.
Je vois que ma remarque tombe à plat ;-( Ne te fatigue pas avec XSLT, la transformation d'un XML n'était pas le point de ma remarque.
-- Gaby
drkm <usenet.fclcxx@fgeorges.org> writes:
| Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
|
| > drkm <usenet.fclcxx@fgeorges.org> writes:
|
| > | La question de la simplicité de la transformation est donc réglée.
| > ^^^^^^^^^^^^^^^^^
|
| > voulais-tu dire « lisibilité » ?
|
| Non. Ce n'était peut être pas clair. Je ne me souviens plus si
| Olivier à expliqué ce qu'était XSLT en l'introduisant dans la
| discussion.
Je vois que ma remarque tombe à plat ;-(
Ne te fatigue pas avec XSLT, la transformation d'un XML n'était pas le
point de ma remarque.
| Gabriel Dos Reis writes: | | > drkm writes: | | > | La question de la simplicité de la transformation est donc réglée. | > ^^^^^^^^^^^^^^^^^ | | > voulais-tu dire « lisibilité » ? | | Non. Ce n'était peut être pas clair. Je ne me souviens plus si | Olivier à expliqué ce qu'était XSLT en l'introduisant dans la | discussion.
Je vois que ma remarque tombe à plat ;-( Ne te fatigue pas avec XSLT, la transformation d'un XML n'était pas le point de ma remarque.
-- Gaby
Gabriel Dos Reis
Olivier Azeau writes:
| drkm wrote: | > Il y a des règles à respecter si tu veux sortir du plain text au | > moyen d'un script XSLT. Surtout au niveau des caractères blancs dont | > fait partie le retour à la ligne. Et tu es tombé dedans en voulant | > montrer la simplicité de la transformation du document XML vers le | > fichier plain text correspondant, orienté-lignes. | | Mais une simplicité, ce n'est jamais quelque chose d'absolu.
N'est-ce pas ?
-- Gaby
Olivier Azeau <john@doe.com> writes:
| drkm wrote:
| > Il y a des règles à respecter si tu veux sortir du plain text au
| > moyen d'un script XSLT. Surtout au niveau des caractères blancs dont
| > fait partie le retour à la ligne. Et tu es tombé dedans en voulant
| > montrer la simplicité de la transformation du document XML vers le
| > fichier plain text correspondant, orienté-lignes.
|
| Mais une simplicité, ce n'est jamais quelque chose d'absolu.
| drkm wrote: | > Il y a des règles à respecter si tu veux sortir du plain text au | > moyen d'un script XSLT. Surtout au niveau des caractères blancs dont | > fait partie le retour à la ligne. Et tu es tombé dedans en voulant | > montrer la simplicité de la transformation du document XML vers le | > fichier plain text correspondant, orienté-lignes. | | Mais une simplicité, ce n'est jamais quelque chose d'absolu.
N'est-ce pas ?
-- Gaby
drkm
Olivier Azeau writes:
drkm wrote:
Olivier Azeau writes:
Mais, comme je l'ai déjà dit dans un autre message, avoir un format d'échange difficilement manipulable hors C++
Tu parles d'ASCII ?!?
ASCII, binaire, peu importe.
L'XML est facilement manipulable en d'autres langages que C++, mais pas l'ASCII ?
--drkm
Olivier Azeau <john@doe.com> writes:
drkm wrote:
Olivier Azeau <john@doe.com> writes:
Mais, comme je l'ai déjà dit dans un autre message, avoir un format
d'échange difficilement manipulable hors C++
Tu parles d'ASCII ?!?
ASCII, binaire, peu importe.
L'XML est facilement manipulable en d'autres langages que C++, mais
pas l'ASCII ?
