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.

[csszzen]

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.

A oui ?

Pourquoi les SGBDR sont peu adaptés ?
Connais tu Alfredsco ? C'est un système apparemment conçu pour ça mais je ne l'ai pas essayé non plus...
C'est dans la boite à veille technologique....

[GrandFather]

Pourquoi les SGBDR sont peu adaptés ?

Le relationnel s'accommode mal de la structure hiérarchique et souple du XML. Ainsi, un modèle de tableau est composé de lignes, elles-mêmes composées de cellules ; une cellule contient des paragraphes, mais peut également contenir d'autres tableaux, et ainsi de suite. Stocker ce modèle récursif dans du relationnel est franchement compliqué, et peu efficace. C'est évidemment un cas extrême, qui suppose qu'on veut gérer individuellement les composantes d'un document avec une granularité très fine, mais ce n'est pas exceptionnel. Si tu gères ton document XML comme un tout monolithique, son stockage dans un SGBDR est moins problématique.

Les bases de données XML sont conçues elles spécifiquement pour le XML, avec des langages de requêtes (XQuery) bien plus adaptés à cet usage que le SQL.

Connais tu Alfredsco ? C'est un système apparemment conçu pour ça mais je ne l'ai pas essayé non plus...
C'est dans la boite à veille technologique....

Je suis dans le public aussi, donc priorité aux solutions libres (et surtout gratuites ). On s'oriente donc plus vers des logiciels comme eXist.

[csszzen]

Le relationnel s'accommode mal de la structure hiérarchique et souple du XML. Ainsi, un modèle de tableau est composé de lignes, elles-mêmes composées de cellules ; une cellule contient des paragraphes, mais peut également contenir d'autres tableaux, et ainsi de suite. Stocker ce modèle récursif dans du relationnel est franchement compliqué, et peu efficace. C'est évidemment un cas extrême, qui suppose qu'on veut gérer individuellement les composantes d'un document avec une granularité très fine, mais ce n'est pas exceptionnel. Si tu gères ton document XML comme un tout monolithique, son stockage dans un SGBDR est moins problématique.

Les bases de données XML sont conçues elles spécifiquement pour le XML, avec des langages de requêtes (XQuery) bien plus adaptés à cet usage que le SQL.

Je suis dans le public aussi, donc priorité aux solutions libres (et surtout gratuites ). On s'oriente donc plus vers des logiciels comme eXist.

Oui, c'est vrai.

Je pensais plus à quelque chose de "simple", articles, titres, sous-titre, contenu, fichiers joints etc... via l'interface web on rempli la base de données et on génère le xml pour un cas précis (selon les grilles de cette parution, je ne tentais pas de faire un outil modulaire qui peut s'adapter à toute parution électronique).

Sinon connais tu cela : http://scenari-platform.org/projects...ri/fr/demo/co/

[csszzen]

Plus personne ne répond ?
Peut être plus d'infos à l'Apple Expo?....

[valal]

slt,

Je viens juste de voir cette discussion, je travaille égalemement dans le domaine de la GED (je fais que ça).

la partie authoring est trés importante dans une chaine de publication XML, mais malhereusement dans le libre il ya pas beaucoup d'outils qui égalent un Xmetal ou un Epic.

de ce qui est du systéme de gestion tu peux effectivement utiliser Alfresco, libre certe mais le support ne l'est pas (les devs non plus). Nous on l'utilise pour un gros client et on a presque tout réecrit.


ou en es tu dans ton projet?

[csszzen]

Je suis allé à un séminaire pendant 2 jours sur les Chaînes Éditoriales Numériques à Angers.
On a des outils libres et gratuits comme Scenari (le livre vient de sortir) ou TextChain (je crois pour le nom je ne suis pas sûr).

ça vous parle ?

Mais ces outils qui permettent de générer des interfaces de saisie (en client ou serveur) créent automatique le xhtml, pdf, swf ou autre et le regénèrent.
Mais ça ne va pas me résoudre mon problème de gestion d'abonnements en lignes !

Alfredsco on m'en a parlé aussi, mais j'ai jamais été fouiller, c'est en Java, donc je ne maitrise pas !
Après si on nous propose une solution qui va dans le sens de cet outil et de la formation, je ne dis pas non !

On va y réfléchir, et vous, d'autres avancées ?

[Morbo]

Salut,
Je travaille aussi dans le secteur publique sur pas mal de projets d'édition.
Je suis développeur donc je me base sur des produits opensource, même si dès fois faut que je fasse avec des produits propriétaires vraiment décevant (Streamserve).
J'utilise pas mal le xml comme format de définition et le framework web Cocoon d'Apache qui s'axe aussi dessus.
Mes utilisateurs ont le plus souvant juste à :

1. sélectionner des dossiers dans une application métier (génération d'xml)
2. y ajouter des données via des formulaires (completer le xml, via les CForms)
3. récupérer un document final (rendering via Birt ou FOP)

.
La définition du workflow se fait dans cocoon à l'aide de fichiers xml.
Le développement de nouveaux types de documents se fait via Birt, le rendering est hélas très lent avec BIRT quant XML est la source de donnée, alors j'utilise Fop en général.
La partie authoring est donc très cadrée dans mon cas et n'est confiée qu'a certains techniciens manipulant Birt et des fichiers xml de définition.