Discussion :

[csszzen]

Bonjour,

certains d'entre vous ont ils déjà vu comment fonctionnait une chaine de production XML de bout en bout, dans l'édition par exemple ?

Je pense à ENI (exemple Nantais), en formation XML il y a peut, le formateur (société externe) nous a dit que maintenant leur livres étaient issus de transformation XSLT d'un XML d'origine pour une impression (donc XSL-FO, pas Force Ouvrière pour les plaisantins tongue.gif ).

Ce XML d'origine permettant d'utiliser le même contenu à plusieurs buts de publication (web et multiformats comme appareils mobiles à surface d'affichage réduite - on a pas encore d'iphone biggrin.gif - ou livres pour l'"habituel").

Seulement je ne vois pas comment concrêtement on défini une telle chaine de travail ?
Ce qu'on peut utiliser en amont pour générer ces fichiers XML, et ce que ça implique en relations de travail.

Car pour le moment ici on est avec d'un côté l'édition qui travaille avec Xpress ou Indesign et qui n'a pas de vision de ce qu'est le web ou les médias + modernes (ebooks) et prie le Dieu PDF ...
et de l'autre avec moi en web avec mes pages statiques pour le moment (la refonte avec outil CMS est en cours) avec ma connaissance du print via un contrat d'un an et demi chez une grande société de l'Ouest (pas le journal, mais un reprographe).

Dans Indesign il existe un module import et export de XML par exemple...

Comment cela se goupille ?

Alors, des témoignages, des opinions sur ce sujet ?


Merci.

[GrandFather]

Bonjour,

Comment cela se goupille ?

je ne connais pas trop le monde de l'édition, par contre j'ai un peu d'expérience sur la gestion documentaire à base de documents XML.

A la production, on trouve des applications spécifiques (rares), des éditeurs XML permettant une saisie selon un schéma prédéfini (Docbook par exemple), soit des suites bureautiques (Word >= 2003 et OpenOffice.org)

A la gestion, le workflow constitué par l'activité des relecteurs, correcteurs, validateurs, etc. est assuré par une application généralement construite autour d'un SGBDR, XML de préférence

A l'édition, le rendu final est effectué avec des transformations XSLT (vers (X)HTML, FO, ...)

[csszzen]

Bonjour,

je ne connais pas trop le monde de l'édition, par contre j'ai un peu d'expérience sur la gestion documentaire à base de documents XML.

A la production, on trouve des applications spécifiques (rares), des éditeurs XML permettant une saisie selon un schéma prédéfini (Docbook par exemple), soit des suites bureautiques (Word >= 2003 et OpenOffice.org)

A la gestion, le workflow constitué par l'activité des relecteurs, correcteurs, validateurs, etc. est assuré par une application généralement construite autour d'un SGBDR, XML de préférence

A l'édition, le rendu final est effectué avec des transformations XSLT (vers (X)HTML, FO, ...)

Bonjour,

merci de ta réponse.

Connais tu des pistes à exploiter ? (livres, liens web ?) Pour approfondir cela ?
Ma chef est ingénieur documentaire, c'est elle qui supervise aussi l'activité web (on est dans le secteur public) et on discute de cela en ce moment pour de l'édition numérique justement (on abandonne l'impression de revues qui étaient imprimées ici, ça revient trop cher...).

Merci.

[GrandFather]

Le domaine est vaste et aggrège beaucoup de technologies différentes, il est difficile de trouver une documentation faisant la synthèse de tout cela.

Si vos critères sont assez exigeants en matière d'édition et si la maquette de votre revue est complexe, il risque d'y avoir une dégradation en passant de XPress à un traitement de texte, que ce soit Word ou OOo. C'est à mon avis la première chose à vérifier avant de se lancer dans de plus amples investigations sur cette possibilité "low-cost".

Sinon, la production du document restera au niveau de XPress, et il faudra alors envisager l'utilisation des fonctions d'import/export XML de XPress. Je n'ai pas travaillé avec le format que XPress utilise et je ne peux donc pas t'en dire plus à ce sujet, par contre la lecture de ce billet de blog devrait t'intéresser.

[csszzen]

Le domaine est vaste et aggrège beaucoup de technologies différentes, il est difficile de trouver une documentation faisant la synthèse de tout cela.

Si vos critères sont assez exigeants en matière d'édition et si la maquette de votre revue est complexe, il risque d'y avoir une dégradation en passant de XPress à un traitement de texte, que ce soit Word ou OOo. C'est à mon avis la première chose à vérifier avant de se lancer dans de plus amples investigations sur cette possibilité "low-cost".

Sinon, la production du document restera au niveau de XPress, et il faudra alors envisager l'utilisation des fonctions d'import/export XML de XPress. Je n'ai pas travaillé avec le format que XPress utilise et je ne peux donc pas t'en dire plus à ce sujet, par contre la lecture de ce billet de blog devrait t'intéresser.

Merci beaucoup pour ce lien.
Je vais lire ça de suite.

Je pensais à une interface de saisie de contenu en PHP renseignant une base de données et/ou générant du xml.
Une fois cela corrigé (fautes d'orthographe), le xml généré permettrait à la PAO d'importer cela dans ses maquettes Indesign (séparation forme/contenu) de manière presque automatique (sauf changements de maquettes graphiques et correction typo pour le print<>de typo pour le web).
De notre côté, ce xml pourrait être transformé en xhtml et donc des pages web en accès restreint...

Qu'en penses tu ?

Merci

Note : on ne va pas concurrencer ENI il s'agit de commencer avec une revue, puis de passer plus tard à de l'édition numérique...

[GrandFather]

Je pensais à une interface de saisie de contenu en PHP renseignant une base de données et/ou générant du xml.
Une fois cela corrigé (fautes d'orthographe), le xml généré permettrait à la PAO d'importer cela dans ses maquettes Indesign (séparation forme/contenu) de manière presque automatique (sauf changements de maquettes graphiques et correction typo pour le print<>de typo pour le web).
De notre côté, ce xml pourrait être transformé en xhtml et donc des pages web en accès restreint...

Ca me semble tout à fait raisonnable, et c'est d'ailleurs la solution mise en avant par l'auteur du blog. Les points délicats que j'y vois sont le fait que le secteur PAO perd toute autonomie pour les modifications de maquette (il va falloir faire avaler cela aux "créa" ), et que les SGBDR classiques sont peu adaptés au stockage de données documentaires.