Christophe de Vienne wroteMais XML _est_ simple...
On voit que tu ne l'as jamais vraiment utilisé:-).
L'avantage du XML, évidemment, c'est que tu peux te télécharger un
parseur qui a des chances de marcher. Si la structure des données est
complexe et variable, et que tu peux te permettre l'expansion de
taille, c'est à considérer pour cette raison. Si la structure n'est
pas complex, il est souvent plus simple d'écrire un parseur de rien
que d'écrire des spécifications XML (le schéma ou le DTD). Et si la
structure est figée, tu n'as pas besoin vraiment d'un parseur, ni de
toutes les informations supplémentaire dans le fichier XML.
Egalement SI on veut que le format soit très facilement lisible par
un programme quelconque don't l'auteur n'aurait pas accès à notre
bibliothèque si portable qu'on a conçu pour ça (voir même sans
documentation),
SI ton application peut utiliser un schéma pré-existant, c'est vrai.
Sinon, ce n'est pas l'utilisation du XML qui va changer quelque chose.
Du XML avec un schéma sur mésure, c'est comme n'importe quel autre
format que tu inventes toi-même.
Christophe de Vienne <cdevienne@alphacent.com> wrote
Mais XML _est_ simple...
On voit que tu ne l'as jamais vraiment utilisé:-).
L'avantage du XML, évidemment, c'est que tu peux te télécharger un
parseur qui a des chances de marcher. Si la structure des données est
complexe et variable, et que tu peux te permettre l'expansion de
taille, c'est à considérer pour cette raison. Si la structure n'est
pas complex, il est souvent plus simple d'écrire un parseur de rien
que d'écrire des spécifications XML (le schéma ou le DTD). Et si la
structure est figée, tu n'as pas besoin vraiment d'un parseur, ni de
toutes les informations supplémentaire dans le fichier XML.
Egalement SI on veut que le format soit très facilement lisible par
un programme quelconque don't l'auteur n'aurait pas accès à notre
bibliothèque si portable qu'on a conçu pour ça (voir même sans
documentation),
SI ton application peut utiliser un schéma pré-existant, c'est vrai.
Sinon, ce n'est pas l'utilisation du XML qui va changer quelque chose.
Du XML avec un schéma sur mésure, c'est comme n'importe quel autre
format que tu inventes toi-même.
Christophe de Vienne wroteMais XML _est_ simple...
On voit que tu ne l'as jamais vraiment utilisé:-).
L'avantage du XML, évidemment, c'est que tu peux te télécharger un
parseur qui a des chances de marcher. Si la structure des données est
complexe et variable, et que tu peux te permettre l'expansion de
taille, c'est à considérer pour cette raison. Si la structure n'est
pas complex, il est souvent plus simple d'écrire un parseur de rien
que d'écrire des spécifications XML (le schéma ou le DTD). Et si la
structure est figée, tu n'as pas besoin vraiment d'un parseur, ni de
toutes les informations supplémentaire dans le fichier XML.
Egalement SI on veut que le format soit très facilement lisible par
un programme quelconque don't l'auteur n'aurait pas accès à notre
bibliothèque si portable qu'on a conçu pour ça (voir même sans
documentation),
SI ton application peut utiliser un schéma pré-existant, c'est vrai.
Sinon, ce n'est pas l'utilisation du XML qui va changer quelque chose.
Du XML avec un schéma sur mésure, c'est comme n'importe quel autre
format que tu inventes toi-même.
Erwann ABALEA wrote in message
news:...On 1 Jul 2003 wrote:
[...]
Comme disent les djeunz, ASN.1 rulez! (ah non, ils ne connaissent pas
l'ASN.1) ;)
ASN.1 est un langage de description des données, non un encodage. Chaque
fois que je l'ai vu, l'encodage était BER. C-à-d à peu près l'équivalent
de XML, mais en binaire.
Je ne connais pas DER. Avec ASN.1 BER, il faudrait bien quelque dizaines
d'octets aussi. Mettons une vingtaine avec BER, et une trentaine avec
XML. Mais c'est difficile à comparer
-- le BER présuppose une
connexion, avec une négotiation des types qu'on est près à accepter
lors de l'établissement de la connexion. Tandis qu'il est concevable à
envoyer un message XML en UDP.
ne vous inquiétez pas, ce n'est pas possible via Usenet :)
-+-LW in Guide du Neuneu Usenet - Après les mouches, à qui le tour ? -+-
Erwann ABALEA <erwann@abalea.com> wrote in message
news:<Pine.LNX.4.33.0307011916330.24603-100000@patchwork.seclogd.org>...
On 1 Jul 2003 kanze@gabi-soft.fr wrote:
[...]
Comme disent les djeunz, ASN.1 rulez! (ah non, ils ne connaissent pas
l'ASN.1) ;)
ASN.1 est un langage de description des données, non un encodage. Chaque
fois que je l'ai vu, l'encodage était BER. C-à-d à peu près l'équivalent
de XML, mais en binaire.
Je ne connais pas DER. Avec ASN.1 BER, il faudrait bien quelque dizaines
d'octets aussi. Mettons une vingtaine avec BER, et une trentaine avec
XML. Mais c'est difficile à comparer
-- le BER présuppose une
connexion, avec une négotiation des types qu'on est près à accepter
lors de l'établissement de la connexion. Tandis qu'il est concevable à
envoyer un message XML en UDP.
ne vous inquiétez pas, ce n'est pas possible via Usenet :)
-+-LW in Guide du Neuneu Usenet - Après les mouches, à qui le tour ? -+-
Erwann ABALEA wrote in message
news:...On 1 Jul 2003 wrote:
[...]
Comme disent les djeunz, ASN.1 rulez! (ah non, ils ne connaissent pas
l'ASN.1) ;)
ASN.1 est un langage de description des données, non un encodage. Chaque
fois que je l'ai vu, l'encodage était BER. C-à-d à peu près l'équivalent
de XML, mais en binaire.
Je ne connais pas DER. Avec ASN.1 BER, il faudrait bien quelque dizaines
d'octets aussi. Mettons une vingtaine avec BER, et une trentaine avec
XML. Mais c'est difficile à comparer
-- le BER présuppose une
connexion, avec une négotiation des types qu'on est près à accepter
lors de l'établissement de la connexion. Tandis qu'il est concevable à
envoyer un message XML en UDP.
ne vous inquiétez pas, ce n'est pas possible via Usenet :)
-+-LW in Guide du Neuneu Usenet - Après les mouches, à qui le tour ? -+-
wrote:L'avantage du XML, évidemment, c'est que tu peux te télécharger un
parseur qui a des chances de marcher. Si la structure des données
est complexe et variable, et que tu peux te permettre l'expansion de
taille, c'est à considérer pour cette raison. Si la structure n'est
pas complex, il est souvent plus simple d'écrire un parseur de rien
que d'écrire des spécifications XML (le schéma ou le DTD). Et si la
structure est figée, tu n'as pas besoin vraiment d'un parseur, ni de
toutes les informations supplémentaire dans le fichier XML.
Dans l'ensemble je pense qu'on est d'accord sur les avantages et
inconvénients de XML. Et je suis d'accord que dans beaucoup de cas
simples un simple fichier texte est largement suffisant. Les fichiers
de configuration de mes programmes ne sont généralement pas en XML.
Egalement SI on veut que le format soit très facilement lisible par
un programme quelconque don't l'auteur n'aurait pas accès à notre
bibliothèque si portable qu'on a conçu pour ça (voir même sans
documentation),
SI ton application peut utiliser un schéma pré-existant, c'est vrai.
Sinon, ce n'est pas l'utilisation du XML qui va changer quelque
chose. Du XML avec un schéma sur mésure, c'est comme n'importe quel
autre format que tu inventes toi-même.
L'avantage que j'y vois est que XML est 'naturellement' lisible (oui,
je sais tout est relatif mais avec un peu d'habitude...).
SI on veut pouvoir lire le fichier en question avec un simple
éditeur de texte,
Un fichier texte est préférable. Toujours, quand on peut. Là, je
suis d'accord. Mais le XML n'est pas le seul format texte possible.
Tout à fait.SI on veut utiliser des encodages ésotériques...
Et pourquoi est-ce qu'on voudrait faire une chose comme ça ? Si mon
programme ne sait pas écrire un encodage, quel est l'intérêt de
l'utiliser.
Pour que les fichiers générés par mon application soient réutilisable
par un programme japonais ? L'UTF-8 comme format de stockage est assez
interessant pour cette raison. Mais en mémoire ce n'est pas forcément
le plus simple. En XML l'UTF-8 est souvent l'encodage par défaut, ce
qui inscite donc à l'utiliser. Alors que sur un format 'perso', il
faut vraiment le vouloir... Cela dit ce n'est pas vraiment un
argument de poids...
kanze@gabi-soft.fr wrote:
L'avantage du XML, évidemment, c'est que tu peux te télécharger un
parseur qui a des chances de marcher. Si la structure des données
est complexe et variable, et que tu peux te permettre l'expansion de
taille, c'est à considérer pour cette raison. Si la structure n'est
pas complex, il est souvent plus simple d'écrire un parseur de rien
que d'écrire des spécifications XML (le schéma ou le DTD). Et si la
structure est figée, tu n'as pas besoin vraiment d'un parseur, ni de
toutes les informations supplémentaire dans le fichier XML.
Dans l'ensemble je pense qu'on est d'accord sur les avantages et
inconvénients de XML. Et je suis d'accord que dans beaucoup de cas
simples un simple fichier texte est largement suffisant. Les fichiers
de configuration de mes programmes ne sont généralement pas en XML.
Egalement SI on veut que le format soit très facilement lisible par
un programme quelconque don't l'auteur n'aurait pas accès à notre
bibliothèque si portable qu'on a conçu pour ça (voir même sans
documentation),
SI ton application peut utiliser un schéma pré-existant, c'est vrai.
Sinon, ce n'est pas l'utilisation du XML qui va changer quelque
chose. Du XML avec un schéma sur mésure, c'est comme n'importe quel
autre format que tu inventes toi-même.
L'avantage que j'y vois est que XML est 'naturellement' lisible (oui,
je sais tout est relatif mais avec un peu d'habitude...).
SI on veut pouvoir lire le fichier en question avec un simple
éditeur de texte,
Un fichier texte est préférable. Toujours, quand on peut. Là, je
suis d'accord. Mais le XML n'est pas le seul format texte possible.
Tout à fait.
SI on veut utiliser des encodages ésotériques...
Et pourquoi est-ce qu'on voudrait faire une chose comme ça ? Si mon
programme ne sait pas écrire un encodage, quel est l'intérêt de
l'utiliser.
Pour que les fichiers générés par mon application soient réutilisable
par un programme japonais ? L'UTF-8 comme format de stockage est assez
interessant pour cette raison. Mais en mémoire ce n'est pas forcément
le plus simple. En XML l'UTF-8 est souvent l'encodage par défaut, ce
qui inscite donc à l'utiliser. Alors que sur un format 'perso', il
faut vraiment le vouloir... Cela dit ce n'est pas vraiment un
argument de poids...
wrote:L'avantage du XML, évidemment, c'est que tu peux te télécharger un
parseur qui a des chances de marcher. Si la structure des données
est complexe et variable, et que tu peux te permettre l'expansion de
taille, c'est à considérer pour cette raison. Si la structure n'est
pas complex, il est souvent plus simple d'écrire un parseur de rien
que d'écrire des spécifications XML (le schéma ou le DTD). Et si la
structure est figée, tu n'as pas besoin vraiment d'un parseur, ni de
toutes les informations supplémentaire dans le fichier XML.
Dans l'ensemble je pense qu'on est d'accord sur les avantages et
inconvénients de XML. Et je suis d'accord que dans beaucoup de cas
simples un simple fichier texte est largement suffisant. Les fichiers
de configuration de mes programmes ne sont généralement pas en XML.
Egalement SI on veut que le format soit très facilement lisible par
un programme quelconque don't l'auteur n'aurait pas accès à notre
bibliothèque si portable qu'on a conçu pour ça (voir même sans
documentation),
SI ton application peut utiliser un schéma pré-existant, c'est vrai.
Sinon, ce n'est pas l'utilisation du XML qui va changer quelque
chose. Du XML avec un schéma sur mésure, c'est comme n'importe quel
autre format que tu inventes toi-même.
L'avantage que j'y vois est que XML est 'naturellement' lisible (oui,
je sais tout est relatif mais avec un peu d'habitude...).
SI on veut pouvoir lire le fichier en question avec un simple
éditeur de texte,
Un fichier texte est préférable. Toujours, quand on peut. Là, je
suis d'accord. Mais le XML n'est pas le seul format texte possible.
Tout à fait.SI on veut utiliser des encodages ésotériques...
Et pourquoi est-ce qu'on voudrait faire une chose comme ça ? Si mon
programme ne sait pas écrire un encodage, quel est l'intérêt de
l'utiliser.
Pour que les fichiers générés par mon application soient réutilisable
par un programme japonais ? L'UTF-8 comme format de stockage est assez
interessant pour cette raison. Mais en mémoire ce n'est pas forcément
le plus simple. En XML l'UTF-8 est souvent l'encodage par défaut, ce
qui inscite donc à l'utiliser. Alors que sur un format 'perso', il
faut vraiment le vouloir... Cela dit ce n'est pas vraiment un
argument de poids...
wrote:Christophe de Vienne wroteMais XML _est_ simple...
On voit que tu ne l'as jamais vraiment utilisé:-).
L'avantage du XML, évidemment, c'est que tu peux te télécharger un
parseur qui a des chances de marcher. Si la structure des données
est complexe et variable, et que tu peux te permettre l'expansion de
taille, c'est à considérer pour cette raison. Si la structure n'est
pas complex, il est souvent plus simple d'écrire un parseur de rien
que d'écrire des spécifications XML (le schéma ou le DTD). Et si la
structure est figée, tu n'as pas besoin vraiment d'un parseur, ni de
toutes les informations supplémentaire dans le fichier XML.
Comment savoir en début de projet que la structure restera figée ?
XML est aussi interressant pour la simplicité d'évolution qu'il
offre.
Egalement SI on veut que le format soit très facilement lisible par
un programme quelconque don't l'auteur n'aurait pas accès à notre
bibliothèque si portable qu'on a conçu pour ça (voir même sans
documentation),
SI ton application peut utiliser un schéma pré-existant, c'est vrai.
Sinon, ce n'est pas l'utilisation du XML qui va changer quelque
chose. Du XML avec un schéma sur mésure, c'est comme n'importe quel
autre format que tu inventes toi-même.
Sauf que tu n'as -à priori- pas à redévelopper les outils de parsing
et de validation.
kanze@gabi-soft.fr wrote:
Christophe de Vienne <cdevienne@alphacent.com> wrote
Mais XML _est_ simple...
On voit que tu ne l'as jamais vraiment utilisé:-).
L'avantage du XML, évidemment, c'est que tu peux te télécharger un
parseur qui a des chances de marcher. Si la structure des données
est complexe et variable, et que tu peux te permettre l'expansion de
taille, c'est à considérer pour cette raison. Si la structure n'est
pas complex, il est souvent plus simple d'écrire un parseur de rien
que d'écrire des spécifications XML (le schéma ou le DTD). Et si la
structure est figée, tu n'as pas besoin vraiment d'un parseur, ni de
toutes les informations supplémentaire dans le fichier XML.
Comment savoir en début de projet que la structure restera figée ?
XML est aussi interressant pour la simplicité d'évolution qu'il
offre.
Egalement SI on veut que le format soit très facilement lisible par
un programme quelconque don't l'auteur n'aurait pas accès à notre
bibliothèque si portable qu'on a conçu pour ça (voir même sans
documentation),
SI ton application peut utiliser un schéma pré-existant, c'est vrai.
Sinon, ce n'est pas l'utilisation du XML qui va changer quelque
chose. Du XML avec un schéma sur mésure, c'est comme n'importe quel
autre format que tu inventes toi-même.
Sauf que tu n'as -à priori- pas à redévelopper les outils de parsing
et de validation.
wrote:Christophe de Vienne wroteMais XML _est_ simple...
On voit que tu ne l'as jamais vraiment utilisé:-).
L'avantage du XML, évidemment, c'est que tu peux te télécharger un
parseur qui a des chances de marcher. Si la structure des données
est complexe et variable, et que tu peux te permettre l'expansion de
taille, c'est à considérer pour cette raison. Si la structure n'est
pas complex, il est souvent plus simple d'écrire un parseur de rien
que d'écrire des spécifications XML (le schéma ou le DTD). Et si la
structure est figée, tu n'as pas besoin vraiment d'un parseur, ni de
toutes les informations supplémentaire dans le fichier XML.
Comment savoir en début de projet que la structure restera figée ?
XML est aussi interressant pour la simplicité d'évolution qu'il
offre.
Egalement SI on veut que le format soit très facilement lisible par
un programme quelconque don't l'auteur n'aurait pas accès à notre
bibliothèque si portable qu'on a conçu pour ça (voir même sans
documentation),
SI ton application peut utiliser un schéma pré-existant, c'est vrai.
Sinon, ce n'est pas l'utilisation du XML qui va changer quelque
chose. Du XML avec un schéma sur mésure, c'est comme n'importe quel
autre format que tu inventes toi-même.
Sauf que tu n'as -à priori- pas à redévelopper les outils de parsing
et de validation.
On 2 Jul 2003 wrote:Erwann ABALEA wrote in message
news:...On 1 Jul 2003 wrote:
[...]Comme disent les djeunz, ASN.1 rulez! (ah non, ils ne connaissent
pas l'ASN.1) ;)
ASN.1 est un langage de description des données, non un encodage.
Chaque fois que je l'ai vu, l'encodage était BER. C-à-d à peu près
l'équivalent de XML, mais en binaire.
Moi je manipule des données encodées DER tous les jours, et je crois
bien que je n'ai pratiquement jamais vu de BER.
Comme quoi... ;) C'est vrai qu'on peut encoder de l'ASN.1 en XML, si
on veut. Mais ça n'est pas la pratique courante.
[...]Je ne connais pas DER. Avec ASN.1 BER, il faudrait bien quelque
dizaines
DER est utilisé quand on veut être certain qu'il n'y a qu'un seul
encodage possible, alors qu'en BER, on peut modifier un peu
l'encodage, du moment que sémantiquement parlant le résultat est
équivalent. Mais à part ça, le BER et le DER sont très proches.
d'octets aussi. Mettons une vingtaine avec BER, et une trentaine
avec XML. Mais c'est difficile à comparer
Là, de mémoire, c'était environ le double (une soixantaine). Et la
valeur sémantique transportée dans l'exemple ne nécessitait pas 20
octets de DER. Encore qu'il est aussi possible de gacher des
ressources en concevant des structures mal foutues...
-- le BER présuppose une
connexion, avec une négotiation des types qu'on est près à accepter
lors de l'établissement de la connexion. Tandis qu'il est concevable à
envoyer un message XML en UDP.
Ni DER ni BER ne présupposent de connexion ou de négociation. Une
application utilisant du BER/DER pour échanger ses données peut
imposer ce mode de fonctionnement, mais c'est lié à l'application
elle-même, pas au codage. Comme je le dis plus haut, je manipule des
données codées en DER tous les jours, et il n'y a pas de connexion à
proprement parler.
On 2 Jul 2003 kanze@gabi-soft.fr wrote:
Erwann ABALEA <erwann@abalea.com> wrote in message
news:<Pine.LNX.4.33.0307011916330.24603-100000@patchwork.seclogd.org>...
On 1 Jul 2003 kanze@gabi-soft.fr wrote:
[...]
Comme disent les djeunz, ASN.1 rulez! (ah non, ils ne connaissent
pas l'ASN.1) ;)
ASN.1 est un langage de description des données, non un encodage.
Chaque fois que je l'ai vu, l'encodage était BER. C-à-d à peu près
l'équivalent de XML, mais en binaire.
Moi je manipule des données encodées DER tous les jours, et je crois
bien que je n'ai pratiquement jamais vu de BER.
Comme quoi... ;) C'est vrai qu'on peut encoder de l'ASN.1 en XML, si
on veut. Mais ça n'est pas la pratique courante.
[...]
Je ne connais pas DER. Avec ASN.1 BER, il faudrait bien quelque
dizaines
DER est utilisé quand on veut être certain qu'il n'y a qu'un seul
encodage possible, alors qu'en BER, on peut modifier un peu
l'encodage, du moment que sémantiquement parlant le résultat est
équivalent. Mais à part ça, le BER et le DER sont très proches.
d'octets aussi. Mettons une vingtaine avec BER, et une trentaine
avec XML. Mais c'est difficile à comparer
Là, de mémoire, c'était environ le double (une soixantaine). Et la
valeur sémantique transportée dans l'exemple ne nécessitait pas 20
octets de DER. Encore qu'il est aussi possible de gacher des
ressources en concevant des structures mal foutues...
-- le BER présuppose une
connexion, avec une négotiation des types qu'on est près à accepter
lors de l'établissement de la connexion. Tandis qu'il est concevable à
envoyer un message XML en UDP.
Ni DER ni BER ne présupposent de connexion ou de négociation. Une
application utilisant du BER/DER pour échanger ses données peut
imposer ce mode de fonctionnement, mais c'est lié à l'application
elle-même, pas au codage. Comme je le dis plus haut, je manipule des
données codées en DER tous les jours, et il n'y a pas de connexion à
proprement parler.
On 2 Jul 2003 wrote:Erwann ABALEA wrote in message
news:...On 1 Jul 2003 wrote:
[...]Comme disent les djeunz, ASN.1 rulez! (ah non, ils ne connaissent
pas l'ASN.1) ;)
ASN.1 est un langage de description des données, non un encodage.
Chaque fois que je l'ai vu, l'encodage était BER. C-à-d à peu près
l'équivalent de XML, mais en binaire.
Moi je manipule des données encodées DER tous les jours, et je crois
bien que je n'ai pratiquement jamais vu de BER.
Comme quoi... ;) C'est vrai qu'on peut encoder de l'ASN.1 en XML, si
on veut. Mais ça n'est pas la pratique courante.
[...]Je ne connais pas DER. Avec ASN.1 BER, il faudrait bien quelque
dizaines
DER est utilisé quand on veut être certain qu'il n'y a qu'un seul
encodage possible, alors qu'en BER, on peut modifier un peu
l'encodage, du moment que sémantiquement parlant le résultat est
équivalent. Mais à part ça, le BER et le DER sont très proches.
d'octets aussi. Mettons une vingtaine avec BER, et une trentaine
avec XML. Mais c'est difficile à comparer
Là, de mémoire, c'était environ le double (une soixantaine). Et la
valeur sémantique transportée dans l'exemple ne nécessitait pas 20
octets de DER. Encore qu'il est aussi possible de gacher des
ressources en concevant des structures mal foutues...
-- le BER présuppose une
connexion, avec une négotiation des types qu'on est près à accepter
lors de l'établissement de la connexion. Tandis qu'il est concevable à
envoyer un message XML en UDP.
Ni DER ni BER ne présupposent de connexion ou de négociation. Une
application utilisant du BER/DER pour échanger ses données peut
imposer ce mode de fonctionnement, mais c'est lié à l'application
elle-même, pas au codage. Comme je le dis plus haut, je manipule des
données codées en DER tous les jours, et il n'y a pas de connexion à
proprement parler.
Erwann ABALEA wrote:Et
pour ça, il fallait plusieurs dizaines d'octets de message, ce qu'on
aurait pu faire en ASN.1 codé DER (ou autre) en quelques octets seulement.
Un exemple aussi minable et un tel gaspillage de ressources, ça m'a
dégouté du machin en question.
La problematique de ton temps (oups, desolé) et celle d'aujourd'hui
n'est plus la meme : avant il fallait caser un maximum d'info dans très
peu de place, aujourd'hui le but est de se faire comprendre par
n'importe quel equipement sans trop programmer.
D'ou la percée d'HTML, XML... et meme des fichiers de configuration de
linux (tout en texte, c'est du rendement? non mais c'est debugable
facilement)
Erwann ABALEA wrote:
Et
pour ça, il fallait plusieurs dizaines d'octets de message, ce qu'on
aurait pu faire en ASN.1 codé DER (ou autre) en quelques octets seulement.
Un exemple aussi minable et un tel gaspillage de ressources, ça m'a
dégouté du machin en question.
La problematique de ton temps (oups, desolé) et celle d'aujourd'hui
n'est plus la meme : avant il fallait caser un maximum d'info dans très
peu de place, aujourd'hui le but est de se faire comprendre par
n'importe quel equipement sans trop programmer.
D'ou la percée d'HTML, XML... et meme des fichiers de configuration de
linux (tout en texte, c'est du rendement? non mais c'est debugable
facilement)
Erwann ABALEA wrote:Et
pour ça, il fallait plusieurs dizaines d'octets de message, ce qu'on
aurait pu faire en ASN.1 codé DER (ou autre) en quelques octets seulement.
Un exemple aussi minable et un tel gaspillage de ressources, ça m'a
dégouté du machin en question.
La problematique de ton temps (oups, desolé) et celle d'aujourd'hui
n'est plus la meme : avant il fallait caser un maximum d'info dans très
peu de place, aujourd'hui le but est de se faire comprendre par
n'importe quel equipement sans trop programmer.
D'ou la percée d'HTML, XML... et meme des fichiers de configuration de
linux (tout en texte, c'est du rendement? non mais c'est debugable
facilement)
Erwann ABALEA wrote:Et pour ça, il fallait plusieurs dizaines d'octets de message, ce
qu'on aurait pu faire en ASN.1 codé DER (ou autre) en quelques
octets seulement. Un exemple aussi minable et un tel gaspillage de
ressources, ça m'a dégouté du machin en question.
La problematique de ton temps (oups, desolé) et celle d'aujourd'hui
n'est plus la meme : avant il fallait caser un maximum d'info dans
très peu de place, aujourd'hui le but est de se faire comprendre par
n'importe quel equipement sans trop programmer.
D'ou la percée d'HTML, XML... et meme des fichiers de configuration de
linux (tout en texte, c'est du rendement? non mais c'est debugable
facilement) qui sont de loin tres fort pour generer des gros fichiers
pour peu d'info :)
Erwann ABALEA wrote:
Et pour ça, il fallait plusieurs dizaines d'octets de message, ce
qu'on aurait pu faire en ASN.1 codé DER (ou autre) en quelques
octets seulement. Un exemple aussi minable et un tel gaspillage de
ressources, ça m'a dégouté du machin en question.
La problematique de ton temps (oups, desolé) et celle d'aujourd'hui
n'est plus la meme : avant il fallait caser un maximum d'info dans
très peu de place, aujourd'hui le but est de se faire comprendre par
n'importe quel equipement sans trop programmer.
D'ou la percée d'HTML, XML... et meme des fichiers de configuration de
linux (tout en texte, c'est du rendement? non mais c'est debugable
facilement) qui sont de loin tres fort pour generer des gros fichiers
pour peu d'info :)
Erwann ABALEA wrote:Et pour ça, il fallait plusieurs dizaines d'octets de message, ce
qu'on aurait pu faire en ASN.1 codé DER (ou autre) en quelques
octets seulement. Un exemple aussi minable et un tel gaspillage de
ressources, ça m'a dégouté du machin en question.
La problematique de ton temps (oups, desolé) et celle d'aujourd'hui
n'est plus la meme : avant il fallait caser un maximum d'info dans
très peu de place, aujourd'hui le but est de se faire comprendre par
n'importe quel equipement sans trop programmer.
D'ou la percée d'HTML, XML... et meme des fichiers de configuration de
linux (tout en texte, c'est du rendement? non mais c'est debugable
facilement) qui sont de loin tres fort pour generer des gros fichiers
pour peu d'info :)
Tout programme de bureautique doit utiliser XML, peut-être, mais pas
forcement pour tout ce qu'il fait. (À mon avis, tout programme qui
génère du texte doit générer du LaTeX. Mais je crois que c'est un
argument perdu d'avance:-).)
Reste évidemment le dernier argument dont je me passerais bien
volontier : C'est à la mode et d'un point de vue marketing ça marche
bien...
Je crois que c'est la raison principale pourquoi j'argue ici. Le XML a
son utilité, et il y a bien des cas où il convient. Mais je crains que
bien tôt souvent, il sert plutôt pour des raisons de marketing que parce
qu'il convient.
Tout programme de bureautique doit utiliser XML, peut-être, mais pas
forcement pour tout ce qu'il fait. (À mon avis, tout programme qui
génère du texte doit générer du LaTeX. Mais je crois que c'est un
argument perdu d'avance:-).)
Reste évidemment le dernier argument dont je me passerais bien
volontier : C'est à la mode et d'un point de vue marketing ça marche
bien...
Je crois que c'est la raison principale pourquoi j'argue ici. Le XML a
son utilité, et il y a bien des cas où il convient. Mais je crains que
bien tôt souvent, il sert plutôt pour des raisons de marketing que parce
qu'il convient.
Tout programme de bureautique doit utiliser XML, peut-être, mais pas
forcement pour tout ce qu'il fait. (À mon avis, tout programme qui
génère du texte doit générer du LaTeX. Mais je crois que c'est un
argument perdu d'avance:-).)
Reste évidemment le dernier argument dont je me passerais bien
volontier : C'est à la mode et d'un point de vue marketing ça marche
bien...
Je crois que c'est la raison principale pourquoi j'argue ici. Le XML a
son utilité, et il y a bien des cas où il convient. Mais je crains que
bien tôt souvent, il sert plutôt pour des raisons de marketing que parce
qu'il convient.
Christophe de Vienne wrote in message
news:<newscache$9a7ghh$g55$...
Tout programme de bureautique doit utiliser XML, peut-être, mais pas
forcement pour tout ce qu'il fait. (À mon avis, tout programme qui
génère du texte doit générer du LaTeX. Mais je crois que c'est un
argument perdu d'avance:-).)
Christophe de Vienne <cdevienne@alphacent.com> wrote in message
news:<newscache$9a7ghh$g55$1@guronzan.alphacent.com>...
Tout programme de bureautique doit utiliser XML, peut-être, mais pas
forcement pour tout ce qu'il fait. (À mon avis, tout programme qui
génère du texte doit générer du LaTeX. Mais je crois que c'est un
argument perdu d'avance:-).)
Christophe de Vienne wrote in message
news:<newscache$9a7ghh$g55$...
Tout programme de bureautique doit utiliser XML, peut-être, mais pas
forcement pour tout ce qu'il fait. (À mon avis, tout programme qui
génère du texte doit générer du LaTeX. Mais je crois que c'est un
argument perdu d'avance:-).)
Tiens, je ne suis pas le seul à préférer le LaTeX à tout autre format,
logiciel, truc pour faire du texte.... ;)
Tiens, je ne suis pas le seul à préférer le LaTeX à tout autre format,
logiciel, truc pour faire du texte.... ;)
Tiens, je ne suis pas le seul à préférer le LaTeX à tout autre format,
logiciel, truc pour faire du texte.... ;)
