RE : [Tsp-devel] XML, Database et Brows e : proposition à TSP

[PAGNOT, Robert]

En réponse à Fréd Deweert & Stéphane Galles.

Est-ce que c'est là que s'interface le provider avec ton butineur? Si,
imaginons, le provider TSP présentait une interface JDBC permettant de
présenter les données, est-ce que ça suffirait pour l'intégrer à ta
chaine d'outils XML?
Oui, le provider TSP mettrait en place une Base de Données (un serveur SQL ou autre source quelconque) avec deux types d'infos : des TEMPLATES (à plat) et des INSTANCES (structurées). Par exemple : un QUATERNIUM est un objet définit par 4 paramètres avec des attributs fixes (nom, unité, précision, ....) - il s'agit donc d'un TEMPLATE. Ensuite, on aura des INSTANCEs de quaternium - repère A vers B, B vers C, ...

Est ce qu'on parle d'une implémentation d'un ORM dont la source de
donnée (ou la génération des données) est indifférement du XML ou du
JDBC ? En fait cela me fait penser à ce que fait Hibernate qui au départ
est plutot un ORM BD; c'est bien quelque chose comme cela ? :
http://www.hibernate.org/hib_docs/v3/reference/en/html/xml.html

Presque ...

D'après ce que tu décris, ta lib fait d'autres choses en plus (notions
de FOLDER si j'ai bien compris), mais on parle bien du même genre de
concept ?

Oui, c'est le même concept, mais en plus souple ...

Ces outils sont issus d'une application VB-beurk (!) qui avait pour contrainte de s'interfacer avec une BD Oracle. J'avais choisi à l'époque (il y a environ 18 mois) de représenter les tables BD en objets XML. Ce dernier ayant la responsabilité de faire le boulot "relationnel" et "metadata".

Avant de me lancer dans le portage JAVA de ce bouzin, je me suis renseigné sur les pratiques courantes. Toutes les solutions que j'ai trouvé ne permettaient pas de dissocier les VALEURs (qui doivent être persistantes et modifiables) des infos "meta" (format, unité, ...). De plus, l'aspect "relationnel" ne doit être géré ni par la base (pour en être indépendant), ni par la structure XML elle même - sans quoi elle serait figée ! C'est-ce que semble proposer l'ORM BD de Stéphane.

Petite précision, ne pas confondre XML et JDBC ...
        XML est un format (certains disent une grammaire) de representation de données relationnelles (donc contextuelles). On peut effetcivement stocker des données en format XML (s'il y a en peu !) dans es fichiers, par un parseur DOM, JDOM ou autres ...

        JDBC est un standard d'accès à une Base de Données, comme ODBC-beurk. Le protocole sous-jacent est du SQL-net. JDBC ne sert pas à stocker des données (sauf de façon temporaire pendant une transaction). Ce n'est donc pas une source de données. La source sera une BD Oracle, MySQL, ... quelque part dans le réseau.

En fait, ma méthode ne suppose RIEN sur la source de données : il s'agit d'un simple repositoire de valeurs - donc même un vulgaire fichier ASCii peut faire l'affaire. Et RIEN non plus sur la façon d'y accéder - il suffit de créer des schéma ad'hoc.

Un exemple débile : une BD Oracle peut-être sérializée en arbre XML via l'utilisation des relative-URI (ou des infos relationnelles de cette BD !), puis accéder par un schema XML://

Un autre interêt est que l'on dissocie complètement les aspects VUE/VALEUR d'un paramètre. Je m'explique : admettons le problème de format d'affichage d'un paramètre TSP. L'attribut "format" est une meta-data de ce paramètre contenu dans un "XML template" qui pourra être différent selon le client. Ce "XML template" sera chargé par l'interface BD à partir d'une source de données qui proposerait N variantes - le choix de la variante étant choisi par le client. On peut ainsi traiter l'internationalisation des affichages (anglais, français, espagnol, ...), mais aussi "limiter" la visibilité/modificabilité de certaines branches (et/ou paramètres) selon le type de client TSP.

Soyons clairs, si un provider TSP mets à disposition une interface BD (serveur SQL, fichier ou autres choses plus simples), cette interface ne fournira que de la meta-data (structuration par le relationnel, user-name, attributs, provider-sid, ....). Le contenu des paramètres devra suivre le canal standard de TSP via l'identifiant provider-sid.

J'espère avoir été (un peu plus) clair !

        Obscur-ô-Bob

_______________________________________________
Tsp-devel mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/tsp-devel

---------------------------------------------------------

CE COURRIER ELECTRONIQUE EST A USAGE STRICTEMENT INFORMATIF ET NE SAURAIT ENGAGER DE QUELQUE MANIERE QUE CE SOIT EADS ASTRIUM SAS, NI SES FILIALES.

SI UNE ERREUR DE TRANSMISSION OU UNE ADRESSE ERRONEE A MAL DIRIGE CE COURRIER, MERCI D'EN INFORMER L'EXPEDITEUR EN LUI FAISANT UNE REPONSE PAR COURRIER ELECTRONIQUE DES RECEPTION. SI VOUS N'ETES PAS LE DESTINATAIRE DE CE COURRIER, VOUS NE DEVEZ PAS L'UTILISER, LE CONSERVER, EN FAIRE ETAT, LE DISTRIBUER, LE COPIER, L'IMPRIMER OU EN REVELER LE CONTENU A UNE TIERCE PARTIE.



This email is for information only and will not bind EADS Astrium SAS in any contract or obligation, nor its subsidiaries.

If you have received it in error, please notify the sender by return email. If you are not the addressee of this email, you must not use, keep, disseminate, copy, print or otherwise deal with it.

---------------------------------------------------------