From: frederic.glorieux@ajlsm.com
Date: 14/02/2004 - 14:23
> alléger les flux intersites
Sur ce sujet, je n'ai ni compétence ni besoin. Et je me demande si
l'enjeu n'est pas très provisoire (ex: pensez aux années d'optimisation
sur la taille des fichiers, et le prix actuel des disques durs, ou la
diffusion des algorythmes de compression).
> Donc je pense qu'un peu d'aide ne sera pas de trop ... et je pense
par la
> suite masteriser sur un CD cette solution pour une installation facile.
Je vous ai exposé mes limites et mes intérêts, mais à l'intérieur, je
suis source ouverte.
> le but est d'instaurer des standart non
> modifiables
Standardiser la maquette d'une organisation, sans trop modifier les
pratiques réelles des producteurs, et s'économiser de la formation
(utilisation des styles, diffusion de templates...), je comprends ce
besoin, et j'y suis confronté en ce moment (mais pas en contexte
industriel). Ethiquement, je préfère former que transformer le travail
des auteurs à leur insu, mais le coût en formation est important.
> Justement, c'est la qu'openoffice intervient.
> Tu a une ligne de commande qui te permet d'envoyer openoffice sans
l'affichage
> graphique ... je pense que c'est une solution à mettre en complement .
Plus d'un seront curieux de vos expérimentations sur la résistance d'oo
dans la montée en charge. Je vais d'ici quelques semaines me remettre à
traiter des collections de word(<= XP) à convertir en oo, je m'inquiète
d'avance.
> J'ai deux cas distincts:
>
> Les documents bureautique (à prendre en compte mais c'est la deuxieme phase du
> projet)
Pensez vous pouvoir faire utiliser OpenOffice à vos producteurs ? Là je
crois que le coût est énorme en formation. Je suppose qu'ils sont sous
MS.Office (XP et avant), et qu'il vous faudra les mouliner (probablement
par OO), et je suppose à un point d'entrée réseau qui vous évite de
déployer la moulinette sur chaque poste de producteur. Maintenant,
considérez le format natif du Office à venir (j'ai évalué la preview il
y a quelques mois), c'est un XML très propre (et je dirais, plus lisible
que celui de OO). Si votre organisation prévoit un déploiement du pack
office, c'est une variable à prendre en compte.
> Les documents issus de la GPAO et des bases de données, ce qui m'interresse
> aujourd'hui. le but est de prendre un fichier de données XML dans un format
> propre de description (etiquettes, facture etc ...).
>
> Ensuite, ces donées arrivent sur le serveur de gestion qui regarde l'entete et
> dis, c'est un etiquette A, avec le format B1, qui doit etre imprimé sur
> l'imprimante P3 du site S2.
>
> ce flux XML est envoye (WebDAV, ipp, sftp, ou autre) sur le serveur
> d'impression du site S2. Celui ci transforme les données XML en un fichier
> XML formaté d'après le modele B1 de l'etiquette A, puis l'imprime sur
> l'imprimante laser P3 en postscript ... ou autre.
Là vous êtes à mon avis dans du spécifique qui peut bien être source
libre, mais qui risque de concerner peu de monde. Par contre, votre doc
sur le process semble apparemment concerner bien d'autres personnes.
> Pourquoi je parlait d'openoffice... Pour les documents bureautiques, ca
> serait simple defaire les modèles en openoffice, puis de faire circuler sur
> le reseau juste le content.xml (avec peut etre les images si necessaires).
Je vous le déconseille. Le gain en taille est faible (et il vous faut
décompresser, extraire, puis recompresser). Par contre, je peux dire que
vous auriez gros intérêt à traiter le meta.xml (stocke les informations
d'identité de votre auteur), et pour des usages sémantiques plus précis
(par styles) il faut parfois fouiller style.xml.
> XSL-FO pour les etiquettes bon de livraison etc ...
Oui, une xsl à faire sur votre XML de sortie (base de données ?) et
branchement sur fop (ou autre composant fo2ps, qu'il faudra peut-être
payer, car fop a des limites et occupe beaucoup de mémoire).
> et Openoffice pour les facture, documents bureautique etc ... le but est que
> l'utilisateur ne soit pas perdu. je ne vais pas lui demander de faire un
> texte brut XML ...
Donc, si vous obteniez que vos utilisateurs passent à OpenOffice (ce qui
est une politique d'entreprise à saluer mais qui ne se décide pas à la
légère), ou en word2003 (ce qui coûte aussi beaucoup), vous avez une XSL
qui nettoie le chose avant de l'imprimer, et qui lui applique la
maquette d'entreprise. Là, probablement que les meilleurs filtres pour
imprimer sont dans les applications elles-mêmes, ce qui voudrait dire un
serveur oo (ou word2003), qui concentrerait toutes les demandes
d'impressions. Rationnel, mais montée en charge ?
> Justement, je me demande comment commencer pour definir un format de données .
> Je travail dans le domaine de l'industrie, et donc j'ai des Bon de livraison,
> ticket vert (suivi des colis), etiquette GALIA, etc qui ont de format visuel
> définit (normés), donc peut etre qu'il existe une description XML. (je n'ai
> pas encore cherché).
Je ne suis pas compétent sur ce sujet, mais je relance votre demande, un
lecteur pourrait avoir une idée
<http://xmlfr.org/actualites/decid/010925-0003> ?
> Qu'entends tu par standart ? et pour toi le schema d'entree c'est les données
> XML pur ou les données XML "mise en page" ?
Tu (?) as je crois à peu près compris la chose. L'intérêt de XML est de
séparer contenu et la présentation, bien. Considérons le rédactionnel
(que je connais mieux que le reste). Dans 10 ans, on se moque qu'un
auteur voulait son titre en bleu clair sur fond orange, surtout s'il
avait un goût, disons... discutable. Par contre, c'est encore le
spécialiste inconditionnel de la fission moléculatoire en eau trouble,
et son article est continuellement cité et resservi à divers endroits du
monde, sous toute sorte de présentation (dont une version braille qui a
fait grand bruit dans la communauté des chimistes aveugles, parce que ce
fut le premier texte scientifique servi avec une présentation proprement
étudiée pour le braille, mais ce bruit ne s'est pas trop entendu
ailleurs, car la communauté est peu nombreuse).
Très bien, mais si chacun a son XML à lui, on se trouve à devoir
développer des transformations pour chaque canaux, avec ses bugs et ses
tests à soi, et 2 mois après, on revient à Word. D'où l'intérêt de se
confier à des standards partagés, documentés, avec de multiples
ressources attenantes. Exemple magistral <http://docbook.org/>, schéma
de la documentation informatique, avec un pack de transformations
activement maintenues, tant vers le web que vers le print.
Donc, si tu veux l'adhésion et le succés de ton projet, tu gagneras à
t'adosser à des schémas largement diffusés (enfin dans les limites de la
petite communauté XML), et ne pas succomber à la tentation de faire tes
éléments à toi (sur le contenu comme la présentation).
C'est tout ce que je voulais dire, et en fait, c'est plutôt des
généralités et des bonnes intentions qui ne t'aident pas concrètement.
--
Frédéric Glorieux http://www.strabon.org
AJLSM, ingénieur documentaire Maison des Sciences de l'Homme
<frederic.glorieux@ajlsm.com> 54 Boulevard Raspail 75006 PARIS
tel +33 (0)1 49 54 22 22 fax +33 (0)1 49 54 21 80
--
Devenez redacteur <XML>fr et contribuez au developpement du
xml francophone (http://xmlfr.org/infos/redacteurs/) !
Liste de diffusion "xml-tech@xmlfr.org" (http://xmlfr.org).
Cette liste est a votre disposition pour discuter en francais de
tout sujet technique lie a XML.
Pour resilier votre abonnement, envoyez un message contenant
la commande "unsubscribe" a xml-tech-request@xmlfr.org
(mailto:xml-tech-request@xmlfr.org?Subject=unsubscribe)
Archive générée par hypermail 2.1.3 le 28/06/2004 - 11:05 UTC
webmaster@xmlfr.org
| 
