xml decid : Stratégies, marchés, affaires autour de XML.
[xml-decid] Re: INFO : Donnees de base INSEE
From: Eric van der Vlist (vdv@dyomedea.com)
Date: 06/03/2004 - 16:56
Bonjour,
On Sat, 2004-03-06 at 16:18, Herve AGNOUX wrote:
> Le Mardi 02 Mars 2004 12:22, redacteurs@xmlfr.org a écrit :
> >
> > Ils sont l'illustration d'une des methodes preconisees pour la
> > publication de vocabulaires XML dans ma presentation « Vers une
> > babelisation de XML ? [14] » effectuee lors de « The XML Day » 2003.
> >
>
> Pourriez-vous développer plus précisément ce point ?... Je veux dire comment
> allez-vous juger que les différents organismes affiliés ou utilisant les
> données INSEE utilisent bien ces vocabulaires, de façon pertinente, dans
> l'intérêt général.
Nous ne jugeons de rien, mais nous cherchons à mettre à la disposition
des personnes (et programmes) des ressources permettant :
* De comprendre comment écrire des documents XML conformes à notre
spécification.
* De faire un certain nombre de contrôles permettant de détecter
certains erreurs.
> Ma question est certainement un peu choquante, alors je vais m'expliquer.
>
> Lorsqu'était paru votre "Vers une babelisation de XML ? ", je n'avais été que
> moyennement d'accord avec ce que vous disiez, même si vous aviez le mérite
> d'ouvrir le débat sur plusieurs points fondamentaux (ce que c'est qu'un
> vocabulaire XML, par ex, etc). Mais je n'avais pas eu le temps, alors,
> d'aller plus loin.
>
> Le problème que je ressens est que vous semblez considérer que la
> babélisation est un défaut en soi, qui ne peut être le fruit que de la
> mauvaise volonté (informaticiens fénéants, sociétés commerciales hypocrites,
> et j'en passe).
C'était volontairement un peu provocateur pour susciter cette
réflexion... Je ne considère pas que le babelisation soit un défaut (il
y a dans le mot "défaut" un aspect jugement de valeur qui me gêne) mais
c'est indiscutablement un problème technique à résoudre pour faire
communiquer des programmes.
> Par conséquent la méthode que vous préconisez pour résoudre
> ce problème fait massivement appel à la bonne volonté et à la rigueur
> (documentation abondante et agréable, guides divers, intégration facile,
> pluralité des portes d'entrée, etc).
Oui.
> La France de l'INSEE (si vous me pardonnez ce raccourci) est certainement un
> bon indicateur de la pertinence de cette approche : c'est une administration,
> me semble-t-il, relativement centralisée, mais placée dans un contexte (la
> France, donc) en pleine décentralisation, que ce soit interne (les régions),
> externe (l'Europe), et même par bien des cotés un contexte en pleine crise (et
> le fait que vous choisissiez un exemple précisement sur la Corse pour
> illustrer la méthode employée est assez amusant).
Il y a également une particularité Corse au niveau de la codification
des départements (ce sont les seuls qui incluent des lettres) qui
nécessite qu'on leur accorde une importance particulière.
> Donc, si vraiment la bonne volonté, avec de la rigueur, comme j'ai cru l'avoir
> compris de votre exposé, sont les conditions nécessaires et suffisantes,
> alors l'INSEE devrait être un bon révélateur, et c'est pour cela que je
> voudrais savoir, dans la mesure où ce n'est pas confidentiel bien sûr, quels
> "indicateurs qualités" vous vous êtes donnés sur ces plans.
Je ne me suis pas fixé d'indicateurs qualités formels mais ai essayé de
garder ces points à l'esprit en concevant cette spécification.
> Mon opinion, vous l'aurez compris, est réservée, non pas que je veuille
> l'échec de votre travail pour l'INSEE, mais que je pense que le refus de la
> babelisation, érigé en principe, est une mauvaise piste. C'est l'intérêt
> commun ("gagnant-gagnant" disent les spécialistes, pour une fois à court
> d'anglicismes) qui est la meilleure parade, non la crainte de Babel.
Je ne pense pas qu'il faille parler de refus de la babelisation mais de
gestion de vocabulaires multiples et vous pouvez voir cette
spécification comme un dictionnaire expliquant chacun des termes.
Libre à vous ensuite d'utiliser ce dictionnaire pour contrôler des
documents (à la manière d'un vérificateur orthographique) ou pour
déterminer des correspondances avec d'autres vocabulaires.
Il y a plusieurs "orientations" prises par cette spécification qui vous
permettent d'aller dans ce sens.
Tout d'abord, nous avons pris soin de définir non seulement des éléments
et attributs mais également des types de données. Cela veut dire que si
vous voulez appeler un numéro de département "department" ou "z523" vous
pouvez le faire et attribuer le type défini dans notre schéma à votre
élément ou attribut.
Ensuite, nous avons inclus dans la définition de nos énumérations des
attributs "dc:title" contenant les noms correspondant aux valeurs
numériques. Cela veut dire que si vous souhaitez définir une nouvelle
nomenclature dans laquelle le département de l'Ain n'est plus 01 mais
"8Z5" vous avez la possibilité d'utiliser le schéma pour construire une
table de transcodage.
> D'abord autant que je m'en souvienne, dans l'histoire biblique, la
> babélisation n'est pas un défaut en soi.
>
> Ensuite, je ne pense pas qu'elle soit le résultat de sentiments plus ou moins
> superficiels, mais elle est au contraire au coeur des relations humaines,
> particulièrement commerciales et culturelles ; deux domaines clefs pour XML.
> Par conséquent, au lieu de compter sur l'uniformité de vocabulaire, il
> vaudrait mieux compter sur la fiabilité de traduction, même si cette dernière
> est toujours imparfaite.
>
> C'est le débat, maintes fois relaté dans ces colonnes par Claude Chiaramonti,
> de la normalisation "contre" la spécialisation. Je crois que c'est le
> "contre" qui est l'erreur fondamentale, et votre exposé s'en protège bien
> quelque fois (lorsque vous dites que les schémas ne cherchent pas à définir
> un document complet, par exemple), mais sans aller jusqu'à analyser ce que
> "document complet" (sous entendu : "et spécialisé") signifie.
>
> Peut-on vraiment croire que des documents rédigés en italien avec des portions
> faisant référence à la langue de Lamartine soit autre chose qu'un document
> très érudit, ou complètement incompréhensible ? Je sais bien que la
> multiplicité des espaces de noms est une pratique courante et bien venue.
> Mais justement, raison de plus pour se demander si elle facilite vraiment
> l'interoperabilité, à savoir comment est-ce que les systèmes informatiques
> doivent être construits pour traiter et organiser des collections de
> vocabulaires plus ou moins indépendants (et tous normalisés, bien sûr) ?
La comparaison entre langages naturels et espaces de noms a ces limites
:) ... Les espaces de noms sont conçus pour permettre de définir des
vocabulaires spécialisés et a pratique courante des espaces de noms
serait plutôt comparable à un document rédigé en français avec des
portions qui seraient des formules mathématiques ou des textes
juridiques (on mélange rarement des espaces de noms mélangeant des
vocabulaires ayant des couvertures fonctionnelles voisines).
> Et je n'essaierai même pas d'imaginer les problèmes humains que cela pose. Je
> peux vous dire que moi, en tant qu'informaticien, j'ai souvent manifesté ma
> "mauvaise volonté" sur ces embrouilles.
>
> Ne voulant pas trop m'engager dans un débat philosophique, et encore moins
> religieux, d'autant plus que je n'ai pas d'exemples concrets à faire valoir
> (à moins qu'il n'y en ait que trop, peut être...), je voudrais surtout
> profiter de votre expérience, et savoir si vraiment, bientôt, les mairies de
> Corse mettront "2A" dans un document XML de l'INSEE, juste grâce à la bonne
> volonté et à la rigueur méthodologique des uns et des autres, notamment
> parisiens et, de façon plus positive, comment vous voyez la notion de
> "document complet", comment est-ce que l'on fait pour vérifier si
> environnement humain et systèmes informatiques intègrent ces "documents
> complets", après avoir construit un "jeu d'éléments" ?
Cela dépasse largement la portée de cette spécification qui, encore une
fois, n'est que de donner des éléments permettant de comprendre comment
utiliser ce vocabulaires et effectuer des contrôles.
Cordialement,
Eric van der Vlist
--
Did you know it? Python has now a Relax NG (partial) implementation.
http://advogato.org/proj/xvif/
Upcoming XML schema languages tutorial:
- Santa Clara -half day- (15/03/2004) http://masl.to/?J24916E96
------------------------------------------------------------------------
Eric van der Vlist http://xmlfr.org http://dyomedea.com
(ISO) RELAX NG ISBN:0-596-00421-4 http://oreilly.com/catalog/relax
(W3C) XML Schema ISBN:0-596-00252-1 http://oreilly.com/catalog/xmlschema
------------------------------------------------------------------------
--
Devenez redacteur <XML>fr et contribuez au developpement
du xml francophone (http://xmlfr.org/infos/redacteurs) !
Liste de diffusion "xml-decid@xmlfr.org" (http://xmlfr.org).
Cette liste est a votre disposition pour discuter en francais de
tout sujet lie a XML.
Pour resilier votre abonnement, envoyez un message contenant la
commande "unsubscribe" a xml-decid-request@xmlfr.org
(mailto:xml-decid-request@xmlfr.org?Subject=unsubscribe)
Archive générée par hypermail 2.1.3 le 30/03/2004 - 14:42 UTC
webmaster@xmlfr.org
| 
