et jusque là quelle la différence avec mes propes formats ASCII?
et jusque là quelle la différence avec mes propes formats ASCII?
et jusque là quelle la différence avec mes propes formats ASCII?
En espérant avoir été assez clair car je ne suis pas spécialiste.
Cordialement
En espérant avoir été assez clair car je ne suis pas spécialiste.
Cordialement
En espérant avoir été assez clair car je ne suis pas spécialiste.
Cordialement
"Arnaud Debaene" writes:
| James Kanze wrote:
|
| >
| >> L'intérêt de sérialiser en XML c'est que XML est portable
| >
| > Pas vraiment. Le syntaxe de base est portable. Mais ça ne suffit
| > pas ; il faut aussi que les deux côtés soient d'accord sur le
| > DTD. Dans les domaines où il y a un DTD standard prédéfini, on
| > peut effectivement parler d'une certaine portabilité. Mes ces
| > domaines font plutôt exception.
| >
| > Dans la pratique, il y a encore peu de cas où XML se justifie.
|
| Je ne suis pas tout à fait d'accord : XML (avec un DTD) permet d'échanger
| des données structurées complexes entre 2 programmes quelconques, même s'ils
| sont écrits avec des langages très différents (C# d'un côté et Perl de
| l'autre par exemple).
et jusque là quelle la différence avec mes propes formats ASCII?
L'existence de parsers déja prêts ? (débuggés, optimisés...)
"Arnaud Debaene" <adebaene@club-internet.fr> writes:
| James Kanze wrote:
|
| >
| >> L'intérêt de sérialiser en XML c'est que XML est portable
| >
| > Pas vraiment. Le syntaxe de base est portable. Mais ça ne suffit
| > pas ; il faut aussi que les deux côtés soient d'accord sur le
| > DTD. Dans les domaines où il y a un DTD standard prédéfini, on
| > peut effectivement parler d'une certaine portabilité. Mes ces
| > domaines font plutôt exception.
| >
| > Dans la pratique, il y a encore peu de cas où XML se justifie.
|
| Je ne suis pas tout à fait d'accord : XML (avec un DTD) permet d'échanger
| des données structurées complexes entre 2 programmes quelconques, même s'ils
| sont écrits avec des langages très différents (C# d'un côté et Perl de
| l'autre par exemple).
et jusque là quelle la différence avec mes propes formats ASCII?
L'existence de parsers déja prêts ? (débuggés, optimisés...)
"Arnaud Debaene" writes:
| James Kanze wrote:
|
| >
| >> L'intérêt de sérialiser en XML c'est que XML est portable
| >
| > Pas vraiment. Le syntaxe de base est portable. Mais ça ne suffit
| > pas ; il faut aussi que les deux côtés soient d'accord sur le
| > DTD. Dans les domaines où il y a un DTD standard prédéfini, on
| > peut effectivement parler d'une certaine portabilité. Mes ces
| > domaines font plutôt exception.
| >
| > Dans la pratique, il y a encore peu de cas où XML se justifie.
|
| Je ne suis pas tout à fait d'accord : XML (avec un DTD) permet d'échanger
| des données structurées complexes entre 2 programmes quelconques, même s'ils
| sont écrits avec des langages très différents (C# d'un côté et Perl de
| l'autre par exemple).
et jusque là quelle la différence avec mes propes formats ASCII?
L'existence de parsers déja prêts ? (débuggés, optimisés...)
Olivier Azeau writes:
| Gabriel Dos Reis wrote:
| > "Arnaud Debaene" writes:
| > | James Kanze wrote:
| > | | >
| > | >> L'intérêt de sérialiser en XML c'est que XML est portable
| > | >
| > | > Pas vraiment. Le syntaxe de base est portable. Mais ça ne suffit
| > | > pas ; il faut aussi que les deux côtés soient d'accord sur le
| > | > DTD. Dans les domaines où il y a un DTD standard prédéfini, on
| > | > peut effectivement parler d'une certaine portabilité. Mes ces
| > | > domaines font plutôt exception.
| > | >
| > | > Dans la pratique, il y a encore peu de cas où XML se justifie.
| > | | Je ne suis pas tout à fait d'accord : XML (avec un DTD) permet
| > d'échanger | des données structurées complexes entre 2 programmes
| > quelconques, même s'ils | sont écrits avec des langages très
| > différents (C# d'un côté et Perl de | l'autre par exemple).
| > et jusque là quelle la différence avec mes propes formats ASCII?
| >
| L'existence de parsers déja prêts ? (débuggés, optimisés...)
Donc, c'est une question de parsers. J'utiliserais un autre mot que
« portabilité » pour décrire la chose, à moins bien sûr qu'on
me demande de travailler au département marketting.
| L'existence d'un mécanisme de validation via une DTD pour le contrôle
| des erreurs ?
Mais cela dépend de mon propre format ASCII : est-il plus simple
d'utiliser ton validateur DTD que mon propre vérificateur de format
qui eput Être de loin plus simple selon mon propre format ASCII ?
Mon propre vérificateur peut être aussi auto-correcteur ou non
redondant.
| L'existence de langages adaptés pour traiter ces informations lors de
| l'échange ? (XSLT)
Mais, cela peut être aussi le cas de mon propre format ASCII (AWK,
Perl, ...).
| L'idiome qui va permettre à un autre développeur de comprendre
| immédiatement ce qui a été fait ?
Mais cela peut être aussi le cas de mon propre format ASCII.
Olivier Azeau <john@doe.com> writes:
| Gabriel Dos Reis wrote:
| > "Arnaud Debaene" <adebaene@club-internet.fr> writes:
| > | James Kanze wrote:
| > | | >
| > | >> L'intérêt de sérialiser en XML c'est que XML est portable
| > | >
| > | > Pas vraiment. Le syntaxe de base est portable. Mais ça ne suffit
| > | > pas ; il faut aussi que les deux côtés soient d'accord sur le
| > | > DTD. Dans les domaines où il y a un DTD standard prédéfini, on
| > | > peut effectivement parler d'une certaine portabilité. Mes ces
| > | > domaines font plutôt exception.
| > | >
| > | > Dans la pratique, il y a encore peu de cas où XML se justifie.
| > | | Je ne suis pas tout à fait d'accord : XML (avec un DTD) permet
| > d'échanger | des données structurées complexes entre 2 programmes
| > quelconques, même s'ils | sont écrits avec des langages très
| > différents (C# d'un côté et Perl de | l'autre par exemple).
| > et jusque là quelle la différence avec mes propes formats ASCII?
| >
| L'existence de parsers déja prêts ? (débuggés, optimisés...)
Donc, c'est une question de parsers. J'utiliserais un autre mot que
« portabilité » pour décrire la chose, à moins bien sûr qu'on
me demande de travailler au département marketting.
| L'existence d'un mécanisme de validation via une DTD pour le contrôle
| des erreurs ?
Mais cela dépend de mon propre format ASCII : est-il plus simple
d'utiliser ton validateur DTD que mon propre vérificateur de format
qui eput Être de loin plus simple selon mon propre format ASCII ?
Mon propre vérificateur peut être aussi auto-correcteur ou non
redondant.
| L'existence de langages adaptés pour traiter ces informations lors de
| l'échange ? (XSLT)
Mais, cela peut être aussi le cas de mon propre format ASCII (AWK,
Perl, ...).
| L'idiome qui va permettre à un autre développeur de comprendre
| immédiatement ce qui a été fait ?
Mais cela peut être aussi le cas de mon propre format ASCII.
Olivier Azeau writes:
| Gabriel Dos Reis wrote:
| > "Arnaud Debaene" writes:
| > | James Kanze wrote:
| > | | >
| > | >> L'intérêt de sérialiser en XML c'est que XML est portable
| > | >
| > | > Pas vraiment. Le syntaxe de base est portable. Mais ça ne suffit
| > | > pas ; il faut aussi que les deux côtés soient d'accord sur le
| > | > DTD. Dans les domaines où il y a un DTD standard prédéfini, on
| > | > peut effectivement parler d'une certaine portabilité. Mes ces
| > | > domaines font plutôt exception.
| > | >
| > | > Dans la pratique, il y a encore peu de cas où XML se justifie.
| > | | Je ne suis pas tout à fait d'accord : XML (avec un DTD) permet
| > d'échanger | des données structurées complexes entre 2 programmes
| > quelconques, même s'ils | sont écrits avec des langages très
| > différents (C# d'un côté et Perl de | l'autre par exemple).
| > et jusque là quelle la différence avec mes propes formats ASCII?
| >
| L'existence de parsers déja prêts ? (débuggés, optimisés...)
Donc, c'est une question de parsers. J'utiliserais un autre mot que
« portabilité » pour décrire la chose, à moins bien sûr qu'on
me demande de travailler au département marketting.
| L'existence d'un mécanisme de validation via une DTD pour le contrôle
| des erreurs ?
Mais cela dépend de mon propre format ASCII : est-il plus simple
d'utiliser ton validateur DTD que mon propre vérificateur de format
qui eput Être de loin plus simple selon mon propre format ASCII ?
Mon propre vérificateur peut être aussi auto-correcteur ou non
redondant.
| L'existence de langages adaptés pour traiter ces informations lors de
| l'échange ? (XSLT)
Mais, cela peut être aussi le cas de mon propre format ASCII (AWK,
Perl, ...).
| L'idiome qui va permettre à un autre développeur de comprendre
| immédiatement ce qui a été fait ?
Mais cela peut être aussi le cas de mon propre format ASCII.
Gabriel Dos Reis wrote:"Arnaud Debaene" writes:
| James Kanze wrote:
| | >
| >> L'intérêt de sérialiser en XML c'est que XML est portable
| >
| > Pas vraiment. Le syntaxe de base est portable. Mais ça ne suffit
| > pas ; il faut aussi que les deux côtés soient d'accord sur le
| > DTD. Dans les domaines où il y a un DTD standard prédéfini, on
| > peut effectivement parler d'une certaine portabilité. Mes ces
| > domaines font plutôt exception.
| >
| > Dans la pratique, il y a encore peu de cas où XML se justifie.
| | Je ne suis pas tout à fait d'accord : XML (avec un DTD) permet
d'échanger | des données structurées complexes entre 2 programmes
quelconques, même s'ils | sont écrits avec des langages très différents
(C# d'un côté et Perl de | l'autre par exemple).
et jusque là quelle la différence avec mes propes formats ASCII?
L'existence de parsers déja prêts ?
(débuggés, optimisés...)
Gabriel Dos Reis wrote:
"Arnaud Debaene" <adebaene@club-internet.fr> writes:
| James Kanze wrote:
| | >
| >> L'intérêt de sérialiser en XML c'est que XML est portable
| >
| > Pas vraiment. Le syntaxe de base est portable. Mais ça ne suffit
| > pas ; il faut aussi que les deux côtés soient d'accord sur le
| > DTD. Dans les domaines où il y a un DTD standard prédéfini, on
| > peut effectivement parler d'une certaine portabilité. Mes ces
| > domaines font plutôt exception.
| >
| > Dans la pratique, il y a encore peu de cas où XML se justifie.
| | Je ne suis pas tout à fait d'accord : XML (avec un DTD) permet
d'échanger | des données structurées complexes entre 2 programmes
quelconques, même s'ils | sont écrits avec des langages très différents
(C# d'un côté et Perl de | l'autre par exemple).
et jusque là quelle la différence avec mes propes formats ASCII?
L'existence de parsers déja prêts ?
(débuggés, optimisés...)
Gabriel Dos Reis wrote:"Arnaud Debaene" writes:
| James Kanze wrote:
| | >
| >> L'intérêt de sérialiser en XML c'est que XML est portable
| >
| > Pas vraiment. Le syntaxe de base est portable. Mais ça ne suffit
| > pas ; il faut aussi que les deux côtés soient d'accord sur le
| > DTD. Dans les domaines où il y a un DTD standard prédéfini, on
| > peut effectivement parler d'une certaine portabilité. Mes ces
| > domaines font plutôt exception.
| >
| > Dans la pratique, il y a encore peu de cas où XML se justifie.
| | Je ne suis pas tout à fait d'accord : XML (avec un DTD) permet
d'échanger | des données structurées complexes entre 2 programmes
quelconques, même s'ils | sont écrits avec des langages très différents
(C# d'un côté et Perl de | l'autre par exemple).
et jusque là quelle la différence avec mes propes formats ASCII?
L'existence de parsers déja prêts ?
(débuggés, optimisés...)
| > | | Je ne suis pas tout à fait d'accord : XML (avec un DTD)
permet
| > d'échanger | des données structurées complexes entre 2
programmes
| > quelconques, même s'ils | sont écrits avec des langages très
| > différents (C# d'un côté et Perl de | l'autre par exemple).
| > et jusque là quelle la différence avec mes propes formats
ASCII?
| >
| L'existence de parsers déja prêts ? (débuggés, optimisés...)
Donc, c'est une question de parsers.
C'est surtout une question de standardisation du format parsé (et de
| L'existence d'un mécanisme de validation via une DTD pour le
contrôle
| des erreurs ?
Mais cela dépend de mon propre format ASCII : est-il plus simple
d'utiliser ton validateur DTD que mon propre vérificateur de format
qui eput Être de loin plus simple selon mon propre format ASCII ?
Mon propre vérificateur peut être aussi auto-correcteur ou non
redondant.
Oui, yapluka l'écrire, et probablement le refaire (ou le modifier)
| L'existence de langages adaptés pour traiter ces informations lors
de
| l'échange ? (XSLT)
Mais, cela peut être aussi le cas de mon propre format ASCII (AWK,
Perl, ...).
On parle de C++, non ?
| L'idiome qui va permettre à un autre développeur de comprendre
| immédiatement ce qui a été fait ?
Mais cela peut être aussi le cas de mon propre format ASCII.
Bref.
Ta réaction me fait un peu penser aux gens qui disent "à quoi ca sert
| > | | Je ne suis pas tout à fait d'accord : XML (avec un DTD)
permet
| > d'échanger | des données structurées complexes entre 2
programmes
| > quelconques, même s'ils | sont écrits avec des langages très
| > différents (C# d'un côté et Perl de | l'autre par exemple).
| > et jusque là quelle la différence avec mes propes formats
ASCII?
| >
| L'existence de parsers déja prêts ? (débuggés, optimisés...)
Donc, c'est une question de parsers.
C'est surtout une question de standardisation du format parsé (et de
| L'existence d'un mécanisme de validation via une DTD pour le
contrôle
| des erreurs ?
Mais cela dépend de mon propre format ASCII : est-il plus simple
d'utiliser ton validateur DTD que mon propre vérificateur de format
qui eput Être de loin plus simple selon mon propre format ASCII ?
Mon propre vérificateur peut être aussi auto-correcteur ou non
redondant.
Oui, yapluka l'écrire, et probablement le refaire (ou le modifier)
| L'existence de langages adaptés pour traiter ces informations lors
de
| l'échange ? (XSLT)
Mais, cela peut être aussi le cas de mon propre format ASCII (AWK,
Perl, ...).
On parle de C++, non ?
| L'idiome qui va permettre à un autre développeur de comprendre
| immédiatement ce qui a été fait ?
Mais cela peut être aussi le cas de mon propre format ASCII.
Bref.
Ta réaction me fait un peu penser aux gens qui disent "à quoi ca sert
| > | | Je ne suis pas tout à fait d'accord : XML (avec un DTD)
permet
| > d'échanger | des données structurées complexes entre 2
programmes
| > quelconques, même s'ils | sont écrits avec des langages très
| > différents (C# d'un côté et Perl de | l'autre par exemple).
| > et jusque là quelle la différence avec mes propes formats
ASCII?
| >
| L'existence de parsers déja prêts ? (débuggés, optimisés...)
Donc, c'est une question de parsers.
C'est surtout une question de standardisation du format parsé (et de
| L'existence d'un mécanisme de validation via une DTD pour le
contrôle
| des erreurs ?
Mais cela dépend de mon propre format ASCII : est-il plus simple
d'utiliser ton validateur DTD que mon propre vérificateur de format
qui eput Être de loin plus simple selon mon propre format ASCII ?
Mon propre vérificateur peut être aussi auto-correcteur ou non
redondant.
Oui, yapluka l'écrire, et probablement le refaire (ou le modifier)
| L'existence de langages adaptés pour traiter ces informations lors
de
| l'échange ? (XSLT)
Mais, cela peut être aussi le cas de mon propre format ASCII (AWK,
Perl, ...).
On parle de C++, non ?
| L'idiome qui va permettre à un autre développeur de comprendre
| immédiatement ce qui a été fait ?
Mais cela peut être aussi le cas de mon propre format ASCII.
Bref.
Ta réaction me fait un peu penser aux gens qui disent "à quoi ca sert