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).
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).
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).
Le problème est que rien ne garantit qu'une plist quelconque peut-être
convertit en une simple liste à plat
Le problème est que rien ne garantit qu'une plist quelconque peut-être
convertit en une simple liste à plat
Le problème est que rien ne garantit qu'une plist quelconque peut-être
convertit en une simple liste à plat
Mais s'il s'agit de convertir un type fichier plist *restreint* dont la
hiérarchie est limitée et dont la sémantique du contenu est connue,
alors passer par une représentation intermédiaire simplifiée (type
plist-text) pourrait éventuellement permettre à Benoît de se passer de
XSLT.
Mais s'il s'agit de convertir un type fichier plist *restreint* dont la
hiérarchie est limitée et dont la sémantique du contenu est connue,
alors passer par une représentation intermédiaire simplifiée (type
plist-text) pourrait éventuellement permettre à Benoît de se passer de
XSLT.
Mais s'il s'agit de convertir un type fichier plist *restreint* dont la
hiérarchie est limitée et dont la sémantique du contenu est connue,
alors passer par une représentation intermédiaire simplifiée (type
plist-text) pourrait éventuellement permettre à Benoît de se passer de
XSLT.
Oui mais ceux qui proposent les plist comme stockage n'offrent pas de
DTD autant que je sache.
Donc si je prends un extrait d'une appli qui gère des livres et stocke les
infos dans une plist dont je veux extraire une partie des infos, les
retraiter pour ensuite créer une bdd importable sur Palm sans passer par
quatre étapes manuelles, comme c'est le cas actuellement dans la majorité
des applis, export de la base puis ouverture dans Excel pour supprimer les
colonnes inutiles puis ouverture dans BBedit pour tout ramener en asccii pur
pour virer les accents & co et enfin lancer une appli qui traduit cela au
format de la base pour le Palm.
Donc pour l'exemple je te donne juste le début de ma base (c'est
loooong) histoire d'atteindre le premier bouquin :
Oui mais ceux qui proposent les plist comme stockage n'offrent pas de
DTD autant que je sache.
Donc si je prends un extrait d'une appli qui gère des livres et stocke les
infos dans une plist dont je veux extraire une partie des infos, les
retraiter pour ensuite créer une bdd importable sur Palm sans passer par
quatre étapes manuelles, comme c'est le cas actuellement dans la majorité
des applis, export de la base puis ouverture dans Excel pour supprimer les
colonnes inutiles puis ouverture dans BBedit pour tout ramener en asccii pur
pour virer les accents & co et enfin lancer une appli qui traduit cela au
format de la base pour le Palm.
Donc pour l'exemple je te donne juste le début de ma base (c'est
loooong) histoire d'atteindre le premier bouquin :
Oui mais ceux qui proposent les plist comme stockage n'offrent pas de
DTD autant que je sache.
Donc si je prends un extrait d'une appli qui gère des livres et stocke les
infos dans une plist dont je veux extraire une partie des infos, les
retraiter pour ensuite créer une bdd importable sur Palm sans passer par
quatre étapes manuelles, comme c'est le cas actuellement dans la majorité
des applis, export de la base puis ouverture dans Excel pour supprimer les
colonnes inutiles puis ouverture dans BBedit pour tout ramener en asccii pur
pour virer les accents & co et enfin lancer une appli qui traduit cela au
format de la base pour le Palm.
Donc pour l'exemple je te donne juste le début de ma base (c'est
loooong) histoire d'atteindre le premier bouquin :
Ben si. Ils utilisent la DTD de PropertyList. D'ailleurs le fichier que vous
nous fournissez commence bien par :
Le problème est que pour rendre ce genre de document manipulable par les
bibliothèques standards, les plist n'incluent aucune information sémantique
dans le balisage. Les balises ne servent qu'à organiser une hiérarchie de
données. On ne sait pas si ces données sont en rapport avec une base de
données de livres, le préférences d'un soft ou les dates de vaccinations du
chat. La DTD PropertyList est donc trop générique pour permettre une
extraction sémantique des données.
Donc si je prends un extrait d'une appli qui gère des livres et stocke les
infos dans une plist dont je veux extraire une partie des infos, les
retraiter pour ensuite créer une bdd importable sur Palm sans passer par
quatre étapes manuelles, comme c'est le cas actuellement dans la majorité
des applis, export de la base puis ouverture dans Excel pour supprimer les
colonnes inutiles puis ouverture dans BBedit pour tout ramener en asccii pur
pour virer les accents & co et enfin lancer une appli qui traduit cela au
format de la base pour le Palm.
Donc pour l'exemple je te donne juste le début de ma base (c'est
loooong) histoire d'atteindre le premier bouquin :
[... extrait d'un fichier plist ...]
Ok (le plus simple serait tout de même de dooner un lien vers un fichier
complet).
Mais qu'attendez-vous en sortie (en supposant qu'on parte de cet exemple) ?
Quels champs ? Dans quel ordre ? Quel encodage ? Regoupés comment ? etc.
De plus, cet exemple n'est pas assez complet. Par exemple, que se passe-t-il
quand il y a plusieurs auteurs ?
ou autre chose ?
Ben si. Ils utilisent la DTD de PropertyList. D'ailleurs le fichier que vous
nous fournissez commence bien par :
Le problème est que pour rendre ce genre de document manipulable par les
bibliothèques standards, les plist n'incluent aucune information sémantique
dans le balisage. Les balises ne servent qu'à organiser une hiérarchie de
données. On ne sait pas si ces données sont en rapport avec une base de
données de livres, le préférences d'un soft ou les dates de vaccinations du
chat. La DTD PropertyList est donc trop générique pour permettre une
extraction sémantique des données.
Donc si je prends un extrait d'une appli qui gère des livres et stocke les
infos dans une plist dont je veux extraire une partie des infos, les
retraiter pour ensuite créer une bdd importable sur Palm sans passer par
quatre étapes manuelles, comme c'est le cas actuellement dans la majorité
des applis, export de la base puis ouverture dans Excel pour supprimer les
colonnes inutiles puis ouverture dans BBedit pour tout ramener en asccii pur
pour virer les accents & co et enfin lancer une appli qui traduit cela au
format de la base pour le Palm.
Donc pour l'exemple je te donne juste le début de ma base (c'est
loooong) histoire d'atteindre le premier bouquin :
[... extrait d'un fichier plist ...]
Ok (le plus simple serait tout de même de dooner un lien vers un fichier
complet).
Mais qu'attendez-vous en sortie (en supposant qu'on parte de cet exemple) ?
Quels champs ? Dans quel ordre ? Quel encodage ? Regoupés comment ? etc.
De plus, cet exemple n'est pas assez complet. Par exemple, que se passe-t-il
quand il y a plusieurs auteurs ?
ou autre chose ?
Ben si. Ils utilisent la DTD de PropertyList. D'ailleurs le fichier que vous
nous fournissez commence bien par :
Le problème est que pour rendre ce genre de document manipulable par les
bibliothèques standards, les plist n'incluent aucune information sémantique
dans le balisage. Les balises ne servent qu'à organiser une hiérarchie de
données. On ne sait pas si ces données sont en rapport avec une base de
données de livres, le préférences d'un soft ou les dates de vaccinations du
chat. La DTD PropertyList est donc trop générique pour permettre une
extraction sémantique des données.
Donc si je prends un extrait d'une appli qui gère des livres et stocke les
infos dans une plist dont je veux extraire une partie des infos, les
retraiter pour ensuite créer une bdd importable sur Palm sans passer par
quatre étapes manuelles, comme c'est le cas actuellement dans la majorité
des applis, export de la base puis ouverture dans Excel pour supprimer les
colonnes inutiles puis ouverture dans BBedit pour tout ramener en asccii pur
pour virer les accents & co et enfin lancer une appli qui traduit cela au
format de la base pour le Palm.
Donc pour l'exemple je te donne juste le début de ma base (c'est
loooong) histoire d'atteindre le premier bouquin :
[... extrait d'un fichier plist ...]
Ok (le plus simple serait tout de même de dooner un lien vers un fichier
complet).
Mais qu'attendez-vous en sortie (en supposant qu'on parte de cet exemple) ?
Quels champs ? Dans quel ordre ? Quel encodage ? Regoupés comment ? etc.
De plus, cet exemple n'est pas assez complet. Par exemple, que se passe-t-il
quand il y a plusieurs auteurs ?
ou autre chose ?
Pour reprendre ta question concernant les listes d'auteurs il est tout
à fait concevable que dans ce cas on préfère générer une string A, B,
C.. à partir d'un array plutot que de créer une arborescence plus
complexe pour ce type d'info.
Si tu veux je peux te faire parvenir par mail un fichier d'exemple (si
tu me donnes ton adresse en écrivant à la mienne qui est un peu plus
valide que la tienne ;-). En tout cas je regarde de plus prés, de mon
côté, l'osax de Smile.
Pour reprendre ta question concernant les listes d'auteurs il est tout
à fait concevable que dans ce cas on préfère générer une string A, B,
C.. à partir d'un array plutot que de créer une arborescence plus
complexe pour ce type d'info.
Si tu veux je peux te faire parvenir par mail un fichier d'exemple (si
tu me donnes ton adresse en écrivant à la mienne qui est un peu plus
valide que la tienne ;-). En tout cas je regarde de plus prés, de mon
côté, l'osax de Smile.
Pour reprendre ta question concernant les listes d'auteurs il est tout
à fait concevable que dans ce cas on préfère générer une string A, B,
C.. à partir d'un array plutot que de créer une arborescence plus
complexe pour ce type d'info.
Si tu veux je peux te faire parvenir par mail un fichier d'exemple (si
tu me donnes ton adresse en écrivant à la mienne qui est un peu plus
valide que la tienne ;-). En tout cas je regarde de plus prés, de mon
côté, l'osax de Smile.
- En XML standard <atom>Hydrogène<atom> on dit que ce qui suit est un
atom.
- En XML plist <key>atom<key><string>Hydrogène<string> on dit toujours
que ce qui suit est dans la "catégorie" atom qui est du type texte brute
dont le contenu est «atom » le type aurait pu être booléen, entier,
nombre, liste... Bref on a toujours une hierarchie à deux niveau à plat
à la fin pour avoir l'info et il faut chercher un <key> et prendre le le
tag qui suit pour obtenir les données :-/
Pfouuuuu ! Si tous les dév sont obligés de passer par là pour gérer
leurs prefs pourquoi aucun n'a fait une petite appli pour qu'on puisse
jouer avec ;-)
J'ai un copain qui a plus de 900 règles dans mail car ceraines datent
d'eMailer, alors... et il voudrait faire le ménage là-dedans mais ce
n'est pasle format XML plist qui permet d'y voir clair.
- En XML standard <atom>Hydrogène<atom> on dit que ce qui suit est un
atom.
- En XML plist <key>atom<key><string>Hydrogène<string> on dit toujours
que ce qui suit est dans la "catégorie" atom qui est du type texte brute
dont le contenu est «atom » le type aurait pu être booléen, entier,
nombre, liste... Bref on a toujours une hierarchie à deux niveau à plat
à la fin pour avoir l'info et il faut chercher un <key> et prendre le le
tag qui suit pour obtenir les données :-/
Pfouuuuu ! Si tous les dév sont obligés de passer par là pour gérer
leurs prefs pourquoi aucun n'a fait une petite appli pour qu'on puisse
jouer avec ;-)
J'ai un copain qui a plus de 900 règles dans mail car ceraines datent
d'eMailer, alors... et il voudrait faire le ménage là-dedans mais ce
n'est pasle format XML plist qui permet d'y voir clair.
- En XML standard <atom>Hydrogène<atom> on dit que ce qui suit est un
atom.
- En XML plist <key>atom<key><string>Hydrogène<string> on dit toujours
que ce qui suit est dans la "catégorie" atom qui est du type texte brute
dont le contenu est «atom » le type aurait pu être booléen, entier,
nombre, liste... Bref on a toujours une hierarchie à deux niveau à plat
à la fin pour avoir l'info et il faut chercher un <key> et prendre le le
tag qui suit pour obtenir les données :-/
Pfouuuuu ! Si tous les dév sont obligés de passer par là pour gérer
leurs prefs pourquoi aucun n'a fait une petite appli pour qu'on puisse
jouer avec ;-)
J'ai un copain qui a plus de 900 règles dans mail car ceraines datent
d'eMailer, alors... et il voudrait faire le ménage là-dedans mais ce
n'est pasle format XML plist qui permet d'y voir clair.