En passant Guillaume, deux choses: une précision sur les informations données par ton "ingénieur", puis les implications de XML qui permettent à un marketer d'appréhender quelques possibilités en terme de fonctionnalité/faisabilité.
En gros, XML c'est pas un langage, mais un 'concept'. C'est une manière de présenter les données, avec des balises < et >. L'HTML et ses balises <BODY> ou <IMG> est un type de XML.
Ceci n'est pas la définition d'XML, mais plutôt de SGML duquel HTML est issu. Et ce même si à l'origine SGML fut développé pour structurer des documents selon un standard ISO, en n'ayant aucunement à l'esprit les possibilités futures avec Internet et HTTP... HTML est un
datagramme d'SGML. C'est fort hein?
XML quant à lui permet de
structurer les documents selon des secteurs d'activité. En ce sens, XML fut créé afin de décrire des informations/données, et non pas pas pour définir une mise en page ou programmer des applications (ces dernières peuvent cependant échancger des données avec d'autres applications ou sites Web/intranet, c'est ce qui fait sa véritable force). Le but: séparer les données communes des interfaces et applications distinctes. Ceci permet :
- de faciliter les échanges de données entre partenaires;
- d'échanger des données dans un environnement hétérogène (par exemple un bureau dont une application qui roule sous Windows doit utiliser les résultats ou données d'une autre application qui roule sous UNIX);
- si l'industrie le voulait, nous pourrions avoir du XML propre au domaine du livre: un ensemble de balises explicites pour les libraires pourraient être adoptées en tant que standard.
En fait, on peut considérer XML/XSL comme un moyen permettant de définir un ensemble de macros dont les codes sous-jascents sont en HTML et/ou CSS, mais aussi
dont l'information décrite par chacune des balises (ou sorte de "macros") est une donnée, et non pas pas une couleur ou une mise en page. En ce sens, un fichier XML contient du code HTML afin de mettre en page les données représentées par les balises définies dans un autre fichier. La technologie XML permet donc de définir un ensemble de balises plus simples à comprendre et à manipuler selon un contexte, un domaine d'activité ou un partenariat, voir à définir un "standard" localisé à un réseau d'affaire ou un domaine d'activité.
Attention: il ne faut pas se laisser impressionner par ce "buzzword" nommé XML. Si ce n'est pas nécessaire pour votre contexte, laissez tomber XML! Outre les points mentionnés plus haut, le seul
avantage d'XML est de forcer l'utilisation du HTML W3C standard, mais vous n'avez pas besoin de XML pour ce faire!
En fait, le gros avantage du XML, c'est que tu peux séparer les données de la présentation.
Pour les avantages réels d'XML, lire les points mentionnés plus haut. La séparation de la mise en page du contenu est offerte par les CSS.
Autant que possible, les nouvelles balises XML ne devraient pas inclure des codes de mise en page! En effet
XML sert à décrire les informations, pas à les présenter (c'est HTML qui fait ce boulôt).
XML c'est bien, mais c'est plus long et plus dur à développer que de l'HTML classique. Donc faut qu'il y ait un retour derrière...
Une fois que le nouveau datagramme XML est développé (ce qui ne se fait qu'une seule fois pour une entreprise donnée), la création de nouvelles pages/contenu est beaucoup plus aisée. Encore une fois, XML n'est utile que si vous devez manipuler des données partagées dans un environnement hétérogène. Quelques exemples de contexte :
- Site Web B2B - Applications de "supply chain automation" (chaînes d'approvisionnement) pour un site e-comm. J'ai moi-même utilisé du XML il y a 2 ans avec Postes Canada pour programmer ma passerelle d'évaluation de la livraison (calcul en temps réel sur mon site e-comm, les informations transitant via un module XML entre Postes Canada et mon site), selon le volume et le poids des items, ainsi que selon les adresse d'origine/destinataire. J'avais aussi tenté de convaincre mes fournisseurs d'adopter une procédure impliquant l'utilisation d'XML pour les mises à jour des catalgues et les commandes, mais (évidemment) ces derniers ont refusé de revoir leur façon de faire... Il a donc fallu que je développe une application qui génère et télécopie automatiquement, et de façon journalière. les bons de commande par fournisseur pour tous les achats Web confirmés.
- Intranet corporatif dont les sources des informations/données sont diverses et résident dans un environnement hétérogène.
- Utilisation par un site Web de données provenant d'une base de données qui génère des fichiers pour XML. La sécurité d'accès aux serveurs est ainsi améliorée, car le fichier XML permet aux scripts Web de ne pas avoir à accéder à un serveur de bases de données. Efficace pour moins de 1000-5000 enregistrements (fiches ou items), sion les performances sont comparables à celles d'un site accédant un serveur de BD.
- Pour un portail, uniformisation (standardisation) de l'accès à la source des informations (si ces dernières proviennent encore une fois d'un environnement hétérogène), ansi que de leur utilisation à l'aide de balises XML.
Pour une entreprise, la décision d'utiliser XML ne peut se faire qu'après une analyse des besoins et de l'architecture informatique en cause.
Pour des partenaires d'affaire, XML est un gros plus! En effet il est alors possible d'échanger des informations de bases de données (ces dernières générant automatiquement les fichiers de données dans le contexte XML), de manière sécuritaire et efficace. Une page Web du partenaire pourrait alors "naviguer" les fichiers XML afin de générer le contenu, ou encore afin de mettre à jour une base de données locale (via des scripts faisant appel à l'ODBC ou l'OLE DB, mais ceci n'a lieu qu'après l'acquisition du fichier XML, donc localement : pas d'accès ODBC scripté via le Web, ce qui est bien car la source reste indépendante du destinataire dans ses processus d'affaire).
Ouf! J'éspère que tout ceci aura réussi à démystifier XML... Au plaisir d'avoir vos commentaires!
