From: Frédéric Glorieux (frederic.glorieux@ajlsm.com)
Date: 06/01/2004 - 15:24
Ce que je vais dire ne va pas faire avancer le schmilblick, mais c'est
un compte-rendu d'expérience, qui pourrait donner des idées (puisque le
seul exemple donné était un livre, autant parler de livre).
J'ai travaillé sur une application bibliographique qui implante du
Xforms (désolé, pas grand chose à télécharger pour l'instant). Le
schéma(DTD) <http://www.biblioml.org/dtds/biblioml_030/html/index.html>
est une transposition du format UNIMARC
<http://www.ifla.org/VI/3/p1996-1/sec-uni.htm>.
Le constat ne correspond pas vraiment aux idées discutées, car le schéma
est bien trop complexe pour générer des formulaires. En fait c'est
exactement le contraire, c'est le formulaire qui indique une manière de
produire du XML conforme à ce schéma.
Pour parler plus clair, que ce soit un livre, un CD, une carte
géographique, chacun de ces documents ont une forme (et souvent
plusieurs) d'enregistrement bibliographique (d'où l'intérêt de XML et
l'impossibilité de SQL). On n'a besoin d'une URL pour cataloguer un site
Web, pas pour un article de presse à qui il faut le journal source, etc.
Donc potentiellement beaucoup de formulaires pour un même schéma, donc
pas générables sur ce schéma.
Après divers rêves et tentatives, il est devenu évident que générer un
formulaire, avec son ergonomie, ses messages, son aide, ses raccourcis
clavier localisés... Et bien cela se fait à la main s'il on veut
vraiment que des gens travaillent avec.
J'ai le souvenir d'une application base de données avec génération
automatique de formulaire web (avec les liaisons...). Outre que cela
exige un modèle de données qui soit compréhensible de l'utilisateur, je
peux vous assurer que ce fut un cauchemar et la majorité se sont
réfugiés dans access.
Je conserve par contre cette idée : un bloc "nom, prénom" par exemple,
ou titre répétable, cela peut valoir la peine de se faire sa collection
de snippet (en je ne sais quelle syntaxe) et changer le path du noeud si
c'est pour un autre schéma.
> Le Mardi 06 Janvier 2004 12:12, Antoine Mensch a écrit :
>
>>Tout d'abord, qu'appelles-tu modèle XForms: est-ce l'élément model, qui
>>contient ou référence généralement le ou les schémas utilisés, l'instance
>>initiale, les instructions permettant d'envoyer le résultat du formulaire
>>au serveur et éventuellement des contraintes d'intégrité supplémentaires,
>>ou est-ce l'aspect graphique du formulaire? Ce qui est simple à partager,
>
>
> C'est l"élément "model". C'est à dire, si je comprends bien tout, de l'élément
> "instance" contenue dans l'élément "model". Tout est encore toufu pour moi,
> mais c'est à ce niveau, dans ma petite idée, que j'aimerais pouvoir organiser
> les informations.
>
> Par exemple soit un livre, dont je voudrais saisir le titre et l'auteur, en
> prévoyant l'adresse de l'auteur. Je peux, bien sûr, prévoir deux modèles
> séparés, et les rassembler lors de la saisie, pour l'aspect graphique. Mais
> je voudrais que la possibilité soir directement inscrite au niveau de
> l'élément "model".
>
> Est-ce possible ? Est-ce même souhaitable ? (je peux me tromper). Et comment ?
>
>
>
>>c'est les schémas, puisqu'ils peuvent être définis dans des documents
>>séparés: tu retrouves alors toute les possibilités de composition et
>>d'héritage des schémas. Le reste du contenu de l'élément model (et en
>
>
> Au niveau des schémas, on peut bien prendre n'importe quel langage de schéma
> au niveau du modèle ?
>
> Et donc si je veux établir des relations entre les modèles de formulaires,
> cela reviendrait à choisir un langage de schéma qui me permette d'établir les
> relations voulues entre différents schémas ?
>
> Question subsidiaire : alors quel langage de schéma ? (je vous demande de
> faire tout mon travail, finalement, et je vous en remercie d'avance).
>
>
>
>>particulier les contraintes d'intégrité) est spécifique à un formulaire. On
>>peut peut-être faire quelque chose avec les mécanismes standards
>>d'inclusion XML (entités) pour définir des contraintes réutilisables, mais
>>ça reste à creuser. Par contre, il n'est pas possible (avec les mécanismes
>
>
> Oui, mais j'ai peur que l'inclusion équivale à la disparition de l'élément
> inclus. Lorsque je parlais de mon formulaire pour le livre, je voudrais que
> le formulaire d'adresse reste identifié comme tel, et non qu'il soit recopié
> et placé dans le formulaire du livre.
>
> Une inclusion avec disparition de l'identité de l'élément d'origine, cela peut
> m'être utile, mais je voudrais surtout des liens conservant l'identité du
> modèle lié.
>
>
>
>>de la spec) de définir un composant graphique réutilisable (par exemple un
>>formulaire de saisie d'adresse basé sur un type schéma correspondant)
>>pouvant être facilement inséré dans un formulaire plus complexe (c'était
>>prévu dans les premiers drafts de la spec, puis ça a disparu). Bien sûr, on
>>peut toujours imaginer un mécanisme de plus haut niveau qui génère des
>>formulaires XForms à partir de briques, mais je ne connais pas d'outils qui
>>le fassent.
>>
>
>
> Au niveau des composants graphiques réutilisables je sais parfaitement me
> débrouiller. Ce que je voudrais savoir, c'est comment cela se passe au niveau
> de l'élément model.
>
>
>>Peux-tu préciser ce que tu cherches à faire?
>>
>
>
> C'est en gros un générateur de formulaires. A partir du modèle, j'imagine d'un
> coté spécifier le composant graphique de saisie, mais également organiser et
> surtout repérer les traitements associés ; c'est pour cela que j'ai besoin de
> conserver l'identité des formulaires liés. Je dis "à partir du modèle" (donc
> bien l'élément model/instance de XForms), mais je me trompe peut être ; peut
> être faut-il que je prévois ces choses à un autre niveau... je ne sais pas
> trop lequel.
>
>
--
Frédéric Glorieux
AJLSM, ingénieur documentaire
<frederic.glorieux@ajlsm.com>
tel +33 (0)1 49 54 22 22
fax +33 (0)1 49 54 21 80
http://www.strabon.org
EUMEDIS - Strabon - WP7 - formation/training
Maison des Sciences de l'Homme
54 Boulevard Raspail
75006 PARIS
--
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:06 UTC
webmaster@xmlfr.org
| 
