Devant la recrudescence de l'utilisation des fichiers xml au sein de
la communauté des développeurs Mac (et je les comprends et félicitent).
Je cherche et ne trouve point un utilitaire qui permette de transformer
un fichier xml en texte tabulé ou .cvs et réciproquement.
J'ai commencé à jeter un ½il à xlt & xslt mais là pour le coup ça me
dépasse complètement. Alors s'il y a des pointeurs dans l'air...
Ah Que merci
--
Nos émissions ont pour vocation de rendre le cerveau disponible :
c'est-à-dire de le divertir, de le détendre pour le préparer entre
deux pubs. Ce que nous vendons à Coca-Cola, c'est du temps de cerveau
humain disponible. (P. Le Lay - TF1)
Les entrées d'un fichier plist sont spécialement prévues pour être facilement mappées sur les structures des APIs qui l'utilisent. Les devs utilisent donc les APIs kivonbien et qui font tout tout seul en ce qui concerne les fichiers plist (qui au passage SONT du xml tout à fait standard, tu as l'air de confondre un tas de trucs j'ai l'impression).
Peut-être mais comme j'avais aussi sous le coude du xml du style :
Et tu comprendras qu'une structure telle que celle qui suit est plus lourde que la mienne (évidemment je ne parle pas du cas des préférences d'applis mais de données strucutrées pour stocker les infos d'un document) :
Je me trompe peut-être mais les deux documents sont bien du xml non ?
Maintenant, si tu veux éventuellement te simplifier la vie, tu peux aussi ouvrir ton fichier plist avec le "PropertyList Editor", faire un "Save As..." et choisir "ASCII Property List File".
Un fichier plist sauvé dans ce format aura des entrées du style
toto = tata;
au lieu de
<key>toto</key><string>tata</string>
Ce qui peut éventuellement être plus digeste pour ce que tu veux faire.
Là je te remercie car je ne l'avais pas vu. Maintenant il faut que je vois comment ramener ça à un tableau et réciproquement. Mais l'idéal est de pouvoir le faire directement sans avoir à passer par une étape intermédiaire supplémentaire qui est d'utiliser PropertyList Editor ;-)
-- Nos émissions ont pour vocation de rendre le cerveau disponible : c'est-à-dire de le divertir, de le détendre pour le préparer entre deux pubs. Ce que nous vendons à Coca-Cola, c'est du temps de cerveau humain disponible. (P. Le Lay - TF1)
Luc Heinrich <lucsky@mac.com> wrote:
Les entrées d'un fichier plist sont spécialement prévues pour être
facilement mappées sur les structures des APIs qui l'utilisent. Les devs
utilisent donc les APIs kivonbien et qui font tout tout seul en ce qui
concerne les fichiers plist (qui au passage SONT du xml tout à fait
standard, tu as l'air de confondre un tas de trucs j'ai l'impression).
Peut-être mais comme j'avais aussi sous le coude du xml du style :
Et tu comprendras qu'une structure telle que celle qui suit est plus
lourde que la mienne (évidemment je ne parle pas du cas des préférences
d'applis mais de données strucutrées pour stocker les infos d'un
document) :
Je me trompe peut-être mais les deux documents sont bien du xml non ?
Maintenant, si tu veux éventuellement te simplifier la vie, tu peux
aussi ouvrir ton fichier plist avec le "PropertyList Editor", faire un
"Save As..." et choisir "ASCII Property List File".
Un fichier plist sauvé dans ce format aura des entrées du style
toto = tata;
au lieu de
<key>toto</key><string>tata</string>
Ce qui peut éventuellement être plus digeste pour ce que tu veux faire.
Là je te remercie car je ne l'avais pas vu. Maintenant il faut que je
vois comment ramener ça à un tableau et réciproquement. Mais l'idéal est
de pouvoir le faire directement sans avoir à passer par une étape
intermédiaire supplémentaire qui est d'utiliser PropertyList Editor ;-)
--
Nos émissions ont pour vocation de rendre le cerveau disponible :
c'est-à-dire de le divertir, de le détendre pour le préparer entre
deux pubs. Ce que nous vendons à Coca-Cola, c'est du temps de cerveau
humain disponible. (P. Le Lay - TF1)
Les entrées d'un fichier plist sont spécialement prévues pour être facilement mappées sur les structures des APIs qui l'utilisent. Les devs utilisent donc les APIs kivonbien et qui font tout tout seul en ce qui concerne les fichiers plist (qui au passage SONT du xml tout à fait standard, tu as l'air de confondre un tas de trucs j'ai l'impression).
Peut-être mais comme j'avais aussi sous le coude du xml du style :
Et tu comprendras qu'une structure telle que celle qui suit est plus lourde que la mienne (évidemment je ne parle pas du cas des préférences d'applis mais de données strucutrées pour stocker les infos d'un document) :
Je me trompe peut-être mais les deux documents sont bien du xml non ?
Maintenant, si tu veux éventuellement te simplifier la vie, tu peux aussi ouvrir ton fichier plist avec le "PropertyList Editor", faire un "Save As..." et choisir "ASCII Property List File".
Un fichier plist sauvé dans ce format aura des entrées du style
toto = tata;
au lieu de
<key>toto</key><string>tata</string>
Ce qui peut éventuellement être plus digeste pour ce que tu veux faire.
Là je te remercie car je ne l'avais pas vu. Maintenant il faut que je vois comment ramener ça à un tableau et réciproquement. Mais l'idéal est de pouvoir le faire directement sans avoir à passer par une étape intermédiaire supplémentaire qui est d'utiliser PropertyList Editor ;-)
-- Nos émissions ont pour vocation de rendre le cerveau disponible : c'est-à-dire de le divertir, de le détendre pour le préparer entre deux pubs. Ce que nous vendons à Coca-Cola, c'est du temps de cerveau humain disponible. (P. Le Lay - TF1)
Paul Gaborit
À (at) Sat, 2 Oct 2004 22:05:11 +0200, (Benoit Leraillez) écrivait (wrote):
Devant la recrudescence de l'utilisation des fichiers xml au sein de la communauté des développeurs Mac (et je les comprends et félicitent). Je cherche et ne trouve point un utilitaire qui permette de transformer un fichier xml en texte tabulé ou .cvs et réciproquement.
J'ai commencé à jeter un oeil à xlt & xslt mais là pour le coup ça me dépasse complètement. Alors s'il y a des pointeurs dans l'air...
Un fichier XML peut avoir un contenu quelconque qui peut être vu comme une arborescence d'éléments (de profondure variable) alors qu'un fichier CSV (ou tabulé) est une matrice.
On peut bien sûr transformé une matrice en un arbre (un élément de premier niveau par ligne et chacun de ces éléments contenant un élément de seconde niveau pour chaque case). Cela ne dit pas comment on nomme ces éléments mais ça peut se concevoir.
L'inverse est infaisable : comment transformer un arbre en une matrice ?
Prenons un exemple : une page Web en XHTML (c'est bien du XML), comment voulez-vous la transformer en un fichier CSV ?
-- Paul Gaborit - <http://www.enstimac.fr/~gaborit/>
À (at) Sat, 2 Oct 2004 22:05:11 +0200,
benoit.sansspam@leraillez.sansspam.com (Benoit Leraillez) écrivait (wrote):
Devant la recrudescence de l'utilisation des fichiers xml au sein de
la communauté des développeurs Mac (et je les comprends et félicitent).
Je cherche et ne trouve point un utilitaire qui permette de transformer
un fichier xml en texte tabulé ou .cvs et réciproquement.
J'ai commencé à jeter un oeil à xlt & xslt mais là pour le coup ça me
dépasse complètement. Alors s'il y a des pointeurs dans l'air...
Un fichier XML peut avoir un contenu quelconque qui peut être vu comme une
arborescence d'éléments (de profondure variable) alors qu'un fichier CSV (ou
tabulé) est une matrice.
On peut bien sûr transformé une matrice en un arbre (un élément de premier
niveau par ligne et chacun de ces éléments contenant un élément de seconde
niveau pour chaque case). Cela ne dit pas comment on nomme ces éléments mais
ça peut se concevoir.
L'inverse est infaisable : comment transformer un arbre en une matrice ?
Prenons un exemple : une page Web en XHTML (c'est bien du XML), comment
voulez-vous la transformer en un fichier CSV ?
--
Paul Gaborit - <http://www.enstimac.fr/~gaborit/>
À (at) Sat, 2 Oct 2004 22:05:11 +0200, (Benoit Leraillez) écrivait (wrote):
Devant la recrudescence de l'utilisation des fichiers xml au sein de la communauté des développeurs Mac (et je les comprends et félicitent). Je cherche et ne trouve point un utilitaire qui permette de transformer un fichier xml en texte tabulé ou .cvs et réciproquement.
J'ai commencé à jeter un oeil à xlt & xslt mais là pour le coup ça me dépasse complètement. Alors s'il y a des pointeurs dans l'air...
Un fichier XML peut avoir un contenu quelconque qui peut être vu comme une arborescence d'éléments (de profondure variable) alors qu'un fichier CSV (ou tabulé) est une matrice.
On peut bien sûr transformé une matrice en un arbre (un élément de premier niveau par ligne et chacun de ces éléments contenant un élément de seconde niveau pour chaque case). Cela ne dit pas comment on nomme ces éléments mais ça peut se concevoir.
L'inverse est infaisable : comment transformer un arbre en une matrice ?
Prenons un exemple : une page Web en XHTML (c'est bien du XML), comment voulez-vous la transformer en un fichier CSV ?
-- Paul Gaborit - <http://www.enstimac.fr/~gaborit/>
Alexis Gottlieb
Benoit Leraillez wrote:
Alexis Gottlieb wrote:
Smile, un environnement AppleScript. Cela nécessite donc d'apprendre le language AppleScript, mais c'est assez simple à aborder et ça vaut le coup si tu cherches à automatiser des taches sous Mac. Ce que tu cherches à faire est tout à fait faisable dans le cadre de ce logiciel.
Merci, j'ai testé et commencé à jouer avec les exmples qu'ils d onnent et quand je me suis mis à voulour jouer avec ce que font les dev Mac là c'est la catastrophe.
En effet, le principe du XML et celui qu'on apprend en utilisant l'exemple de Smile, est de partir à la recherchde de tag <ATOM> et de récupérer ce qu'ils contiennent. Bref du XML on ne peut plus classi que.
Par contre dans le monde Mac tout le monde utilise de la plist comme format, même pour ses documents internes voire ses documents et là tout change. Exemple :
L'osax XMLLib de Smile gère les xml mais aussi les plist. cf http://www.satimage.fr/software/fr/plist_suite.html
n'hésite pas à t'inscrire à la liste de discussion de smile pour demander de l'aide, cf http://www.satimage.fr/software/fr/support.html
Alexis Gottlieb Satimage
Benoit Leraillez wrote:
Alexis Gottlieb <alexis_gottlieb_nospam@hotmail.com> wrote:
Smile, un environnement AppleScript. Cela nécessite donc d'apprendre le
language AppleScript, mais c'est assez simple à aborder et ça vaut le coup
si tu cherches à automatiser des taches sous Mac. Ce que tu cherches à
faire est tout à fait faisable dans le cadre de ce logiciel.
Merci, j'ai testé et commencé à jouer avec les exmples qu'ils d onnent
et quand je me suis mis à voulour jouer avec ce que font les dev Mac là
c'est la catastrophe.
En effet, le principe du XML et celui qu'on apprend en utilisant
l'exemple de Smile, est de partir à la recherchde de tag <ATOM> et de
récupérer ce qu'ils contiennent. Bref du XML on ne peut plus classi que.
Par contre dans le monde Mac tout le monde utilise de la plist comme
format, même pour ses documents internes voire ses documents et là tout
change. Exemple :
L'osax XMLLib de Smile gère les xml mais aussi les plist. cf
http://www.satimage.fr/software/fr/plist_suite.html
n'hésite pas à t'inscrire à la liste de discussion de smile pour
demander de l'aide, cf http://www.satimage.fr/software/fr/support.html
Smile, un environnement AppleScript. Cela nécessite donc d'apprendre le language AppleScript, mais c'est assez simple à aborder et ça vaut le coup si tu cherches à automatiser des taches sous Mac. Ce que tu cherches à faire est tout à fait faisable dans le cadre de ce logiciel.
Merci, j'ai testé et commencé à jouer avec les exmples qu'ils d onnent et quand je me suis mis à voulour jouer avec ce que font les dev Mac là c'est la catastrophe.
En effet, le principe du XML et celui qu'on apprend en utilisant l'exemple de Smile, est de partir à la recherchde de tag <ATOM> et de récupérer ce qu'ils contiennent. Bref du XML on ne peut plus classi que.
Par contre dans le monde Mac tout le monde utilise de la plist comme format, même pour ses documents internes voire ses documents et là tout change. Exemple :
L'osax XMLLib de Smile gère les xml mais aussi les plist. cf http://www.satimage.fr/software/fr/plist_suite.html
n'hésite pas à t'inscrire à la liste de discussion de smile pour demander de l'aide, cf http://www.satimage.fr/software/fr/support.html
Alexis Gottlieb Satimage
Alexis Gottlieb
Benoit Leraillez wrote:
Alexis Gottlieb wrote:
Smile, un environnement AppleScript. Cela nécessite donc d'apprendre le language AppleScript, mais c'est assez simple à aborder et ça vaut le coup si tu cherches à automatiser des taches sous Mac. Ce que tu cherches à faire est tout à fait faisable dans le cadre de ce logiciel.
Merci, j'ai testé et commencé à jouer avec les exmples qu'ils d onnent et quand je me suis mis à voulour jouer avec ce que font les dev Mac là c'est la catastrophe.
En effet, le principe du XML et celui qu'on apprend en utilisant l'exemple de Smile, est de partir à la recherchde de tag <ATOM> et de récupérer ce qu'ils contiennent. Bref du XML on ne peut plus classi que.
Par contre dans le monde Mac tout le monde utilise de la plist comme format, même pour ses documents internes voire ses documents et là tout change.
En fait l'osax XMLLib de Smile permet de gérer toute sorte de XML, implémente XPATH et XSLT, mais en ce qui te concerne, elle possède au ssi une suite sur les plist, cf http://www.satimage.fr/software/fr/plist_suite.html
avec ça il est très simple de lister les éléments de ta plist et dans une boucle de les ajouter successivement à du texte ou à une liste...
N'hésite pas à t'inscrire à la mailing liste de Smile pour demander de l'aide : http://www.satimage.fr/software/fr/support.html
Alexis Gottlieb Satimage
Benoit Leraillez wrote:
Alexis Gottlieb <alexis_gottlieb_nospam@hotmail.com> wrote:
Smile, un environnement AppleScript. Cela nécessite donc d'apprendre le
language AppleScript, mais c'est assez simple à aborder et ça vaut le coup
si tu cherches à automatiser des taches sous Mac. Ce que tu cherches à
faire est tout à fait faisable dans le cadre de ce logiciel.
Merci, j'ai testé et commencé à jouer avec les exmples qu'ils d onnent
et quand je me suis mis à voulour jouer avec ce que font les dev Mac là
c'est la catastrophe.
En effet, le principe du XML et celui qu'on apprend en utilisant
l'exemple de Smile, est de partir à la recherchde de tag <ATOM> et de
récupérer ce qu'ils contiennent. Bref du XML on ne peut plus classi que.
Par contre dans le monde Mac tout le monde utilise de la plist comme
format, même pour ses documents internes voire ses documents et là tout
change.
En fait l'osax XMLLib de Smile permet de gérer toute sorte de XML,
implémente XPATH et XSLT, mais en ce qui te concerne, elle possède au ssi
une suite sur les plist, cf
http://www.satimage.fr/software/fr/plist_suite.html
avec ça il est très simple de lister les éléments de ta plist et dans
une boucle de les ajouter successivement à du texte ou à une liste...
N'hésite pas à t'inscrire à la mailing liste de Smile pour demander de
l'aide : http://www.satimage.fr/software/fr/support.html
Smile, un environnement AppleScript. Cela nécessite donc d'apprendre le language AppleScript, mais c'est assez simple à aborder et ça vaut le coup si tu cherches à automatiser des taches sous Mac. Ce que tu cherches à faire est tout à fait faisable dans le cadre de ce logiciel.
Merci, j'ai testé et commencé à jouer avec les exmples qu'ils d onnent et quand je me suis mis à voulour jouer avec ce que font les dev Mac là c'est la catastrophe.
En effet, le principe du XML et celui qu'on apprend en utilisant l'exemple de Smile, est de partir à la recherchde de tag <ATOM> et de récupérer ce qu'ils contiennent. Bref du XML on ne peut plus classi que.
Par contre dans le monde Mac tout le monde utilise de la plist comme format, même pour ses documents internes voire ses documents et là tout change.
En fait l'osax XMLLib de Smile permet de gérer toute sorte de XML, implémente XPATH et XSLT, mais en ce qui te concerne, elle possède au ssi une suite sur les plist, cf http://www.satimage.fr/software/fr/plist_suite.html
avec ça il est très simple de lister les éléments de ta plist et dans une boucle de les ajouter successivement à du texte ou à une liste...
N'hésite pas à t'inscrire à la mailing liste de Smile pour demander de l'aide : http://www.satimage.fr/software/fr/support.html
Alexis Gottlieb Satimage
benoit.sansspam
Paul Gaborit wrote:
L'inverse est infaisable : comment transformer un arbre en une matrice ?
Prenons un exemple : une page Web en XHTML (c'est bien du XML), comment voulez-vous la transformer en un fichier CSV ?
Tous les fichiers XML ne sont pas transformables mais certains le sont. L'exemple que j'ai donné, la table périodique des éléments en est un, la liste des règles de filtrage et le carnet d'adresse de Mail en sont une autre. Les bdd des applis qui gèrent les DVD, CD et livres sur le Mac en sont encore d'autes exemples. Et les outils simples et directes pour générer des fichiers importables sur le Palm, par exemple,...
Il y a donc des tables simples qui peuvent être générées et réciproquement. Je n'ai jamais imaginé pouvoir tout faire car on s'attaque alors à des tableaux multidimensionnels (il peut et il y en a souvent plusieurs), voire pire et là...
-- Nos émissions ont pour vocation de rendre le cerveau disponible : c'est-à-dire de le divertir, de le détendre pour le préparer entre deux pubs. Ce que nous vendons à Coca-Cola, c'est du temps de cerveau humain disponible. (P. Le Lay - TF1)
Paul Gaborit <Paul.Gaborit@invalid.invalid> wrote:
L'inverse est infaisable : comment transformer un arbre en une matrice ?
Prenons un exemple : une page Web en XHTML (c'est bien du XML), comment
voulez-vous la transformer en un fichier CSV ?
Tous les fichiers XML ne sont pas transformables mais certains le
sont. L'exemple que j'ai donné, la table périodique des éléments en est
un, la liste des règles de filtrage et le carnet d'adresse de Mail en
sont une autre. Les bdd des applis qui gèrent les DVD, CD et livres sur
le Mac en sont encore d'autes exemples. Et les outils simples et
directes pour générer des fichiers importables sur le Palm, par
exemple,...
Il y a donc des tables simples qui peuvent être générées et
réciproquement. Je n'ai jamais imaginé pouvoir tout faire car on
s'attaque alors à des tableaux multidimensionnels (il peut et il y en a
souvent plusieurs), voire pire et là...
--
Nos émissions ont pour vocation de rendre le cerveau disponible :
c'est-à-dire de le divertir, de le détendre pour le préparer entre
deux pubs. Ce que nous vendons à Coca-Cola, c'est du temps de cerveau
humain disponible. (P. Le Lay - TF1)
L'inverse est infaisable : comment transformer un arbre en une matrice ?
Prenons un exemple : une page Web en XHTML (c'est bien du XML), comment voulez-vous la transformer en un fichier CSV ?
Tous les fichiers XML ne sont pas transformables mais certains le sont. L'exemple que j'ai donné, la table périodique des éléments en est un, la liste des règles de filtrage et le carnet d'adresse de Mail en sont une autre. Les bdd des applis qui gèrent les DVD, CD et livres sur le Mac en sont encore d'autes exemples. Et les outils simples et directes pour générer des fichiers importables sur le Palm, par exemple,...
Il y a donc des tables simples qui peuvent être générées et réciproquement. Je n'ai jamais imaginé pouvoir tout faire car on s'attaque alors à des tableaux multidimensionnels (il peut et il y en a souvent plusieurs), voire pire et là...
-- Nos émissions ont pour vocation de rendre le cerveau disponible : c'est-à-dire de le divertir, de le détendre pour le préparer entre deux pubs. Ce que nous vendons à Coca-Cola, c'est du temps de cerveau humain disponible. (P. Le Lay - TF1)
benoit.sansspam
Alexis Gottlieb wrote:
En fait l'osax XMLLib de Smile permet de gérer toute sorte de XML, implémente XPATH et XSLT, mais en ce qui te concerne, elle possède aussi une suite sur les plist, cf http://www.satimage.fr/software/fr/plist_suite.html
Merci j'avais pas vu. Mais d'où vient cette suite ?
-- Nos émissions ont pour vocation de rendre le cerveau disponible : c'est-à-dire de le divertir, de le détendre pour le préparer entre deux pubs. Ce que nous vendons à Coca-Cola, c'est du temps de cerveau humain disponible. (P. Le Lay - TF1)
Alexis Gottlieb <alexis_gottlieb_nospam@hotmail.com> wrote:
En fait l'osax XMLLib de Smile permet de gérer toute sorte de XML,
implémente XPATH et XSLT, mais en ce qui te concerne, elle possède aussi
une suite sur les plist, cf
http://www.satimage.fr/software/fr/plist_suite.html
Merci j'avais pas vu. Mais d'où vient cette suite ?
--
Nos émissions ont pour vocation de rendre le cerveau disponible :
c'est-à-dire de le divertir, de le détendre pour le préparer entre
deux pubs. Ce que nous vendons à Coca-Cola, c'est du temps de cerveau
humain disponible. (P. Le Lay - TF1)
En fait l'osax XMLLib de Smile permet de gérer toute sorte de XML, implémente XPATH et XSLT, mais en ce qui te concerne, elle possède aussi une suite sur les plist, cf http://www.satimage.fr/software/fr/plist_suite.html
Merci j'avais pas vu. Mais d'où vient cette suite ?
-- Nos émissions ont pour vocation de rendre le cerveau disponible : c'est-à-dire de le divertir, de le détendre pour le préparer entre deux pubs. Ce que nous vendons à Coca-Cola, c'est du temps de cerveau humain disponible. (P. Le Lay - TF1)
francois.jacquemin
Luc Heinrich wrote:
Un fichier plist sauvé dans ce format aura des entrées du style
toto = tata;
au lieu de
<key>toto</key><string>tata</string>
Oui, mais non. L'intérêt de la plist est de déclarer que toto est de type string tout en donnant du contenu à une variable en contournant la simplicité d'un langage à balise. C'est assez génial. Ce peut être intéressant de stocker tout ça dans une base MySQL avec des tables de <key>, des tables de contenu comportant type et données et liées au premières. Après ça devient plus facile à ressortir sous forme de plist, sous forme simplifiée, sous forme de variables dans un programme etc. -- F. Jacquemin
Luc Heinrich <lucsky@mac.com> wrote:
Un fichier plist sauvé dans ce format aura des entrées du style
toto = tata;
au lieu de
<key>toto</key><string>tata</string>
Oui, mais non. L'intérêt de la plist est de déclarer que toto est de
type string tout en donnant du contenu à une variable en contournant la
simplicité d'un langage à balise. C'est assez génial. Ce peut être
intéressant de stocker tout ça dans une base MySQL avec des tables de
<key>, des tables de contenu comportant type et données et liées au
premières. Après ça devient plus facile à ressortir sous forme de plist,
sous forme simplifiée, sous forme de variables dans un programme etc.
--
F. Jacquemin
Un fichier plist sauvé dans ce format aura des entrées du style
toto = tata;
au lieu de
<key>toto</key><string>tata</string>
Oui, mais non. L'intérêt de la plist est de déclarer que toto est de type string tout en donnant du contenu à une variable en contournant la simplicité d'un langage à balise. C'est assez génial. Ce peut être intéressant de stocker tout ça dans une base MySQL avec des tables de <key>, des tables de contenu comportant type et données et liées au premières. Après ça devient plus facile à ressortir sous forme de plist, sous forme simplifiée, sous forme de variables dans un programme etc. -- F. Jacquemin
lucsky
François Jacquemin wrote:
Oui, mais non. L'intérêt de la plist est de déclarer que toto est de type string tout en donnant du contenu à une variable en contournant la simplicité d'un langage à balise.
Heu, je rappelle que la question initiale est de triturer un fichier plist pour en faire un csv, le typage des entrées n'a *strictement* aucune utilité dans ce cas là. Passer à une forme 'key = value' permet simplement d'éviter de se palucher un parser xml, ce qui peut peut massivement simplifier la tâche si la hierarchie de conteneurs du fichier plist le permet.
-- Luc Heinrich -
François Jacquemin <francois.jacquemin@free.fr> wrote:
Oui, mais non. L'intérêt de la plist est de déclarer que toto est de
type string tout en donnant du contenu à une variable en contournant la
simplicité d'un langage à balise.
Heu, je rappelle que la question initiale est de triturer un fichier
plist pour en faire un csv, le typage des entrées n'a *strictement*
aucune utilité dans ce cas là. Passer à une forme 'key = value' permet
simplement d'éviter de se palucher un parser xml, ce qui peut peut
massivement simplifier la tâche si la hierarchie de conteneurs du
fichier plist le permet.
Oui, mais non. L'intérêt de la plist est de déclarer que toto est de type string tout en donnant du contenu à une variable en contournant la simplicité d'un langage à balise.
Heu, je rappelle que la question initiale est de triturer un fichier plist pour en faire un csv, le typage des entrées n'a *strictement* aucune utilité dans ce cas là. Passer à une forme 'key = value' permet simplement d'éviter de se palucher un parser xml, ce qui peut peut massivement simplifier la tâche si la hierarchie de conteneurs du fichier plist le permet.
-- Luc Heinrich -
Paul Gaborit
À (at) Mon, 4 Oct 2004 20:28:28 +0200, (Benoit Leraillez) écrivait (wrote):
Tous les fichiers XML ne sont pas transformables mais certains le sont.
Ok.
L'exemple que j'ai donné, la table périodique des éléments en est un,
Ça dépend fortement de la manière dont le fichier XML a été conçu. On peut imaginer de multiples manières de décrire la table périodique des éléments en XML. Et pour chacune de ces manières, la conversion en un fichier CSV sera différente et pourra perdre des informations.
la liste des règles de filtrage et le carnet d'adresse de Mail en sont une autre. Les bdd des applis qui gèrent les DVD, CD et livres sur le Mac en sont encore d'autes exemples. Et les outils simples et directes pour générer des fichiers importables sur le Palm, par exemple,...
Je ne connais pas le format XML de chacun de ces exemples mais il y a de grandes chances que ces formats ne se ressemblent pas. On ne peut donc pas concevoir une moulinette générale pour les convertir en CSV.
Il y a donc des tables simples qui peuvent être générées et réciproquement. Je n'ai jamais imaginé pouvoir tout faire car on s'attaque alors à des tableaux multidimensionnels (il peut et il y en a souvent plusieurs), voire pire et là...
Ok. Donc si vous nous donnez un exemple de fichier XML ou mieux une DTD ou un schéma décrivant le format XML des fichiers que vous voulez convertir ainsi qu'un exemple de résultat attendu, il est possible de concevoir la moulinette qui le fera (le plus générique consisterait à utiliser XSLT).
-- Paul Gaborit - <http://www.enstimac.fr/~gaborit/>
À (at) Mon, 4 Oct 2004 20:28:28 +0200,
benoit.sansspam@leraillez.sansspam.com (Benoit Leraillez) écrivait (wrote):
Tous les fichiers XML ne sont pas transformables mais certains le
sont.
Ok.
L'exemple que j'ai donné, la table périodique des éléments en est
un,
Ça dépend fortement de la manière dont le fichier XML a été conçu. On peut
imaginer de multiples manières de décrire la table périodique des éléments en
XML. Et pour chacune de ces manières, la conversion en un fichier CSV sera
différente et pourra perdre des informations.
la liste des règles de filtrage et le carnet d'adresse de Mail en
sont une autre. Les bdd des applis qui gèrent les DVD, CD et livres sur
le Mac en sont encore d'autes exemples. Et les outils simples et
directes pour générer des fichiers importables sur le Palm, par
exemple,...
Je ne connais pas le format XML de chacun de ces exemples mais il y a de
grandes chances que ces formats ne se ressemblent pas. On ne peut donc pas
concevoir une moulinette générale pour les convertir en CSV.
Il y a donc des tables simples qui peuvent être générées et
réciproquement. Je n'ai jamais imaginé pouvoir tout faire car on
s'attaque alors à des tableaux multidimensionnels (il peut et il y en a
souvent plusieurs), voire pire et là...
Ok. Donc si vous nous donnez un exemple de fichier XML ou mieux une DTD ou un
schéma décrivant le format XML des fichiers que vous voulez convertir ainsi
qu'un exemple de résultat attendu, il est possible de concevoir la moulinette
qui le fera (le plus générique consisterait à utiliser XSLT).
--
Paul Gaborit - <http://www.enstimac.fr/~gaborit/>
À (at) Mon, 4 Oct 2004 20:28:28 +0200, (Benoit Leraillez) écrivait (wrote):
Tous les fichiers XML ne sont pas transformables mais certains le sont.
Ok.
L'exemple que j'ai donné, la table périodique des éléments en est un,
Ça dépend fortement de la manière dont le fichier XML a été conçu. On peut imaginer de multiples manières de décrire la table périodique des éléments en XML. Et pour chacune de ces manières, la conversion en un fichier CSV sera différente et pourra perdre des informations.
la liste des règles de filtrage et le carnet d'adresse de Mail en sont une autre. Les bdd des applis qui gèrent les DVD, CD et livres sur le Mac en sont encore d'autes exemples. Et les outils simples et directes pour générer des fichiers importables sur le Palm, par exemple,...
Je ne connais pas le format XML de chacun de ces exemples mais il y a de grandes chances que ces formats ne se ressemblent pas. On ne peut donc pas concevoir une moulinette générale pour les convertir en CSV.
Il y a donc des tables simples qui peuvent être générées et réciproquement. Je n'ai jamais imaginé pouvoir tout faire car on s'attaque alors à des tableaux multidimensionnels (il peut et il y en a souvent plusieurs), voire pire et là...
Ok. Donc si vous nous donnez un exemple de fichier XML ou mieux une DTD ou un schéma décrivant le format XML des fichiers que vous voulez convertir ainsi qu'un exemple de résultat attendu, il est possible de concevoir la moulinette qui le fera (le plus générique consisterait à utiliser XSLT).
-- Paul Gaborit - <http://www.enstimac.fr/~gaborit/>
Paul Gaborit
À (at) Tue, 5 Oct 2004 10:38:18 +0200, (Luc Heinrich) écrivait (wrote):
Heu, je rappelle que la question initiale est de triturer un fichier plist pour en faire un csv, le typage des entrées n'a *strictement* aucune utilité dans ce cas là. Passer à une forme 'key = value' permet simplement d'éviter de se palucher un parser xml, ce qui peut peut massivement simplifier la tâche si la hierarchie de conteneurs du fichier plist le permet.
Le problème est que rien ne garantit qu'une plist quelconque peut-être convertit en une simple liste à plat : la DTD des PropertyList (/System/Library/DTDs/PropertyList.dtd) est implicitement hiérarchique (à cause des collections 'array' et 'dict').
Même en supposant qu'un logiciel utilise une plist qui semble être une liste à plat, rien ne garantit que cette plist le restera...
-- Paul Gaborit - <http://www.enstimac.fr/~gaborit/>
À (at) Tue, 5 Oct 2004 10:38:18 +0200,
lucsky@mac.com (Luc Heinrich) écrivait (wrote):
Heu, je rappelle que la question initiale est de triturer un fichier
plist pour en faire un csv, le typage des entrées n'a *strictement*
aucune utilité dans ce cas là. Passer à une forme 'key = value' permet
simplement d'éviter de se palucher un parser xml, ce qui peut peut
massivement simplifier la tâche si la hierarchie de conteneurs du
fichier plist le permet.
Le problème est que rien ne garantit qu'une plist quelconque peut-être
convertit en une simple liste à plat : la DTD des PropertyList
(/System/Library/DTDs/PropertyList.dtd) est implicitement hiérarchique (à
cause des collections 'array' et 'dict').
Même en supposant qu'un logiciel utilise une plist qui semble être une liste à
plat, rien ne garantit que cette plist le restera...
--
Paul Gaborit - <http://www.enstimac.fr/~gaborit/>
À (at) Tue, 5 Oct 2004 10:38:18 +0200, (Luc Heinrich) écrivait (wrote):
Heu, je rappelle que la question initiale est de triturer un fichier plist pour en faire un csv, le typage des entrées n'a *strictement* aucune utilité dans ce cas là. Passer à une forme 'key = value' permet simplement d'éviter de se palucher un parser xml, ce qui peut peut massivement simplifier la tâche si la hierarchie de conteneurs du fichier plist le permet.
Le problème est que rien ne garantit qu'une plist quelconque peut-être convertit en une simple liste à plat : la DTD des PropertyList (/System/Library/DTDs/PropertyList.dtd) est implicitement hiérarchique (à cause des collections 'array' et 'dict').
Même en supposant qu'un logiciel utilise une plist qui semble être une liste à plat, rien ne garantit que cette plist le restera...
-- Paul Gaborit - <http://www.enstimac.fr/~gaborit/>
