Open XML et les schémas métier : un aperçu

Par Bernard Ourghanlian, Chief Technical & Security Officer – Microsoft France

Introduction

Il semble qu’une certaine confusion règne autour de la notion de « schémas métier ». On entend ainsi parler du fait que l’objectif des schémas métier serait de créer de nouveaux formats de fichiers propriétaires. Il n’en est rien bien sur et la notion de schéma métier et la manière dont ils sont supportés par Open XML méritent d’être développée. Le sujet étant riche il sera développé en plusieurs parties. Le contenu de cette série d’article est largement inspiré des explications données par Doug Mahugh et Brian Jones sur leurs blogs respectifs.

L’un des objectifs d’Open XML est de passer d’un format de fichier binaire (l’ancien format de fichiers d’Office), plat et centré sur le document à un format riche, ouvert et centré sur les données. Autrement dit, en dehors de la nécessité impérieuse de documenter les formats de fichier afin d’en permettre la conservation sur le moyen et long terme dans un environnement où de plus en plus de contenu informationnel est accessible sous forme numérique, une des raisons essentielles qui a poussé Microsoft à l’adoption de XML comme base de son format de documents est précisément de permettre de centrer le format sur les données qui sont, elles, au cœur de tous les processus métier de l’entreprise.

L’unique raison de définir des schémas métier est donc, dans un contexte centré sur les données, de donner du sens à ces données et de faire en sorte que lorsque l’on échange, par exemple, des données entre deux banques, le sens des informations liées à la description d’un compte client soit la même ; de même entre deux administrations, le fait que les coordonnées d’un assuré social ou d’un contribuable aient le même sens au sein des systèmes d’information de différents ministères. Car l’objectif ici est d’aller au-delà de l’interopérabilité technique et de permettre l’interopérabilité sémantique sans laquelle aucune interopérabilité réelle n’est possible. Autrement dit, les schémas métiers ne permettent pas – contrairement à ce qui a pu être dit ici ou là – de définir des formats propriétaires mais tout au contraire de faciliter l’échange des données contenues dans les formats de fichier en leur donnant du sens. Tout leur sens.

Ici, l’approche unique d’Open XML est de permettre ce que l’on pourrait appeler « l’interopérabilité verticale », c'est-à-dire la possibilité d’intégrer d’autres types de systèmes et de données avec des documents Open XML tout en maintenant une séparation nette et simple entre la présentation (Open XML markup) et les données (les schémas métiers, que l’on appelle aussi schémas customisés, et les instances afférentes).

Mais revenons un cours instant sur l’interopérabilité. L’interopérabilité est l’un de ces mots polysémiques qui peuvent vouloir dire des choses différentes pour chacun d’entre-nous. Nous sommes tous d’accord sur le fait que l’interopérabilité signifie quelque chose comme « la possibilité pour des systèmes de travailler efficacement ensemble » mais, comme souvent, dès que l’on rentre dans les détails, les choses se compliquent. Considérons, par exemple, la répartition suivante de produits et de services métier sous la forme d’une classification en domaines « horizontaux » et « verticaux » ainsi qu’indiqué sur le graphique suivant :

Le concept fondamental sous-jacent à un domaine vertical consiste tout simplement dans le fait qu’il représente l’ensemble des activités métiers au sein d’une industrie donnée (la finance ou la construction manufacturière par exemple) sans se préoccuper en aucune façon des types de systèmes ou de logiciels qui y sont utilisés, alors qu’un domaine horizontal pour l’informatique (le marché du traitement de texte, par exemple) correspond à un ensemble de fonctionnalités utilisé par plusieurs industries. Bien entendu, le graphique ci-dessus est très simplificateur et ne saurait prétendre à l’exhaustivité.

Ceci dit, quand on utilise le mot interopérabilité, que peut bien représenter ce mot dans un tel contexte ? Parle-t-on d’interopérabilité horizontale – par exemple d’interopérabilité entre différents tableurs – ou d’interopérabilité verticale, telle que l’interopérabilité entre tous les systèmes utilisés au sein d’une banque, voire même de l’ensemble des systèmes utilisés au sein de la communauté bancaire ?

Bien entendu la réponse à une telle question dépend de sa perspective personnelle, en particulier du milieu professionnel qui est le sien. Pour ceux qui travaillent dans le métier du logiciel, il est tentant de voir le monde en termes de type d’applications : traitement de texte, tableur, messagerie, etc. Et l’on tend alors à un certain strabisme qui conduit à penser l’interopérabilité en des termes horizontaux : deux programmes de traitement de texte peuvent-ils partager des documents ? Deux bases de données peuvent-elles partager des données ?

De même, si l’on travaille dans une entreprise où la technologie informatique ne représente qu’un outil et non l’essentiel de son métier (on est donc dans un domaine vertical), sa vue de l’interopérabilité présente probablement un autre type de strabisme. Par exemple, si l’on travaille dans une entreprise manufacturière, on perçoit probablement l’interopérabilité en termes de capacité pour des systèmes différents – ERP, comptabilité, distribution, logistique – à communiquer efficacement entre eux.

De même, il peut y avoir des besoins d’interopérabilité horizontale au sein d’un domaine vertical. Par exemple, si l’on a mis à jour une version d’un traitement de texte donné, on veut être certain que l’on pourra ouvrir sans surprise les anciens documents avec le nouveau logiciel. Par contre, il est rare que l’on utilise deux programmes de traitement de texte sur le même poste de travail car, dans la majorité des entreprises, quel que soit leur métier, on essaye de standardiser les applications horizontales à chaque fois que c’est possible afin de réduire les coûts de support et de maintenance.

Formats de documents et interopérabilité

Les formats standards de documents jouent un rôle important dans cette vision horizontale/verticale de l’interopérabilité car ils permettent l’interopérabilité des deux types. Par exemple, les formats Open XML permettent l’interopérabilité horizontale en supportant toutes les fonctionnalités existantes au sein des documents binaires d’Office et ils permettent également l’interopérabilité verticale à travers le support de la notion de schémas métiers. Par ailleurs, le traducteur Open XML / ODF permet d’étendre la notion d’interopérabilité horizontale en fournissant un pont entre les mondes de documents Open XML et ODF.

Un autre concept qui est étroitement relié aux questions d’interopérabilité horizontale/verticale des formats de documents est la différence entre la notion d’interopérabilité technique et la notion d’interopérabilité sémantique dont nous avons déjà parlé. Ainsi, l’interopérabilité technique entre des applications de traitement de texte signifie que l’on dispose d’une méthode standard pour marquer un texte en caractères gras, pour indiquer la taille de sa police de caractères, etc. L’interopérabilité sémantique, quant à elle, intervient quand on cherche à standardiser la façon dont on représente une notion purement métier comme un client, une commande, une facture, etc. Si l’on se réfère au graphique précédent, l’interopérabilité sémantique permet l’interopérabilité verticale, alors que l’interopérabilité technique permet l’interopérabilité horizontale.

L’interopérabilité sémantique est généralement quelque chose de bien plus difficile à atteindre que l’interopérabilité technique car les besoins de chaque industrie sont différents. Chacun comprend le concept d’un texte en gras, mais seuls ceux qui travaillent dans l’assurance comprennent les détails de la notion d’une limite de responsabilité, d’une franchise ou d’un contrat d’assurance, alors que ceux qui travaillent dans l’industrie automobile connaitront tout des caractéristiques d’un moteur, d’un échappement ou d’une boîte de vitesse. Ainsi donc, chaque industrie a naturellement la tendance d’utiliser son propre jargon et ce jargon a souvent besoin d’être codifié et standardisé au sein d’un schéma qui définit la structure des documents XML qui sont utilisés au sein de cette industrie.

Le support des schémas customisés au sein d’Open XML

Au sein d’Open XML, il y a deux approches générales pour supporter ces schémas customisés (les spécifications d’Open XML font référence à ses propres schémas sous le nom de reference schemas et appelle tous les autres schémas – tels que les schémas propres à une industrie ou à un métier – sous le nom de custom schemas).

Le premier type de support de schéma customisé correspond à la notion de custom XML markup, ou d’étiquetage de contenu customisé. On peut utiliser un schéma customisé pour étiqueter le contenu d’un document de traitement de texte, par exemple en insérant des éléments customXml autour d’éléments de contenu au sein du corps d’un document, comme suit :

<customXml uri="http://MyNamespace" element="MyElement">
    ... content that is tagged with this element ...
</customXml>

Les usages typiques d’une telle approche correspondent à la volonté d’étiqueter un contenu au sein d’un document pour identifier le numéro de client ou le numéro de commande pour un système de traitement des commandes ou bien pour étiqueter le titre ou l’abstract d’un document pour un système de gestion de contenu. Ce type d’étiquetage de contenu peut être imbriqué autant que nécessaire ainsi que requis par son propre schéma et il y a des options au sein de Microsoft Word pour étiqueter un contenu au travers d’une interface homme – machine simple à utiliser. Les documents générés de manière programmatique peuvent également bénéficier de ce type de fonctionnalité en utilisant la syntaxe de l’exemple ci-dessus.

Il est important de noter que les éléments customisés ne sont pas ajoutés directement au balisage du document. En effet, il y a un élément customXml qui est déjà défini dans les schémas de référence et les éléments customisés (ici, dans l’exemple, MyElement) apparaissent comme des attributs de l’élément customXml. Cette approche simple et flexible est aussi utilisée dans ce que l’on appelle des micro-formats que nous ne traiterons pas ici et qui permettent de la même façon d’ajouter de la sémantique aux pages XHTML sans le besoin d’ajouter de nouveaux éléments ou de changer des schémas de référence existants.

Cette notion de custom XML markup constitue un mécanisme pour étiqueter le contenu au sein du corps d’un document selon un schéma arbitraire. Ceci a pour conséquence d’entrelacer la sémantique métier avec les données de présentation, ce qui – même si c’est la norme dans de nombreux formats de document – n’est pas idéal sur le plan architectural puisqu’il n’y a pas de séparation nette entre la présentation et les données.

Il y a pourtant un type assez banal de scénario dans lequel la notion de custom XML markup fait du sens, celui d’un document déjà existant dont le contenu a besoin d’être étiqueté à l’aide d’une sémantique métier. Par exemple un document qui a été créé des années auparavant et qui doit être enregistré dans un système de gestion de contenu qui lira les métadonnées, telles que l’abstract de ce document, depuis le document lui-même. Dans un tel scénario cette notion de custom XML markup peut être utilisée pour identifier l’abstract et le système de gestion de contenu pourra alors utiliser une simple expression XPath pour rechercher l’abstract au sein du corps du document.

L’interface homme – machine de Word 2007 permet un support facile de cette notion d’étiquetage de contenu. Voici les principales étapes à suivre pour cela :

  1. Être sûr que l’onglet « Developer » est visible au sein du ruban. (Ce n’est pas le cas par défaut ; donc si l’on ne voit pas cet onglet, il suffit de cliquer sur le logo Office en haut à gauche, puis sur les options de Word et de s’assurer que l’option « Show Developer tab in the Ribbon » est sélectionnée)
  2. Ouvrir ou créer un document ; il suffit d’avoir un peu de contenu au sein du document.
  3. Cliquer alors sur l’onglet « Developer », puis sur « Schema » (dans le groupe XML) et ajouter ou attacher un schéma à votre document.

Vous êtes alors prêt à étiqueter le contenu. Sélectionner alors du texte dans votre document et cliquer sur un élément dans le panneau « XML structure » sur la droite afin d’étiqueter le texte ainsi sélectionné. En voici un exemple :

sampledoc.jpg

Le panneau « XML structure » et le contenu du document montrent tout deux la sélection courante et il y a un lien bidirectionnel entre eux : si l’on clique sur la balise dans le document, alors le nœud du schéma est mis en évidence et vice-versa. Ceci permet de voir facilement la structure de la sémantique que l’on ajoute au document.

Pour l’utilisateur, c’est tout ce qu’il a besoin de savoir de la notion de custom XML markup. Pour le développeur, il est toutefois nécessaire de connaitre les détails sous-jacents afin de comprendre comment le contenu est étiqueté de telle façon que l’on puisse écrire du code permettant de retrouver les nœuds au sein de son schéma customisé.

Pour illustrer ces détails, voici un document Open XML d’exemple très simple dans lequel on voit ce que l’on trouve dans le corps du document (dans le document document.xml du répertoire Word puisque c’est là que Word place l’élément de démarrage par défaut) :

samplemarkup.jpg

Un autre moyen au travers duquel Open XML supporte les schémas customisés consiste en l’utilisation des XML parts customisés qui peuvent reposer sur n’importe quel schéma. Ces parts sont insérées au sein d’un document comme un ilot isolé de données métier et les nœuds de ces données métier peuvent alors être reliées à des éléments de présentation comme les balises de document structurées (content controls). Cette architecture permet très simplement à des applications métier de lire et d’écrire les données métier contenues dans un document sans avoir à traiter (et même sans y être exposé) le balisage relatif au document lui-même.

Le support des schémas customisés : ce qui n’est pas nouveau

Comme on vient de le voir, Open XML, comme de nombreux formats de documents, permet l’utilisation de métadonnées extensibles. On peut ajouter des métadonnées pour aider à la description de son document et Word 2007 dispose d’une fonctionnalité intéressante qui permet de faire apparaitre les métadonnées customisées dans un « document information panel » situé au-dessus du document en cours d’édition. Mais l’extensibilité des métadonnées n’est pas quelque-chose de nouveau et le domaine d’application d’une telle fonctionnalité est assez étroit car les éléments que l’on ajoute sont simplement décrits dans le document lui-même.

samplemarkup_2.jpg

Open XML permet également l’utilisation d’un balisage customisé au sein du corps d’un document et ceci constitue un moyen commode pour les utilisateurs de marquer leur contenu afin de permettre l’interopérabilité avec d’autres types de logiciels tels qu’un logiciel métier particulier (c’est ce que l’on vient juste de voir ci-dessus).

Cette notion de balisage customisée n’est pas nouvelle : de nombreux formats permettent cela et Word 2003 offrait déjà cette notion de custom markup qui a déjà été utilisée largement dans des logiciels applicatifs couvrant, par exemple, les domaines de la fabrication manufacturière ou de la législation ainsi que d’autres domaines applicatifs. La manière spécifique utilisée par Open XML pour implémenter ce balisage customisé en utilisant des attributs pour encoder une sémantique permet donc, pour n’importe quel schéma, d’être utilisé de manière extrêmement flexible si on la compare à d’autres approches, mais le concept de base de balisage Open XML customisé n’est pas nouveau.

Ce qui est nouveau

Il y a un domaine où Open XML apporte une nouveauté réelle et qui consiste en son support de custom XML parts au sein d’un package OPC (Open Packaging Conventions). Grâce à cette fonctionnalité, il est possible de placer n’importe quel fichier XML existant au sein d’un document Open XML et ce fichier XML peut être ou non exposé à l’utilisateur en fonction de son choix. Il n’y a donc pas besoin de changer quoi que ce soit à son fichier XML, ni au balisage de son document et il n’est pas nécessaire de faire interférer son balisage customisé et le balisage de son document au sein du même part ou du même fichier (comme bien souvent dans les scénarios de balisage customisé).

Open XML permet d’utiliser les messages XML qui sont utilisés aujourd’hui – les mêmes que ceux qui sont générés par ses logiciels métier, les même qui sont échangés entre ses systèmes à travers des services Web – directement au sein des documents, comme ils sont, sans y changer quoi que ce soit. Il n’y a donc pas à écrire de code pour extraire des données métiers du balisage d’un document car les deux n’ont jamais été mixés ensemble.

Ceci permet la mise en œuvre d’une interopérabilité simple et puissante. Une telle interopérabilité n’est, en l’état actuel des choses, disponible qu’au sein d’un format standardisé tel qu’Open XML qui utilise une convention de packaging standardisé et flexible telle qu’OPC afin de permettre l’ajout de n’importe quel type de contenu à un document de telle façon qu’il n’y ait aucune interférence avec l’architecture du document lui-même (ces concepts ne sont pas d’ailleurs limitées aux données XML mais nous nous limiterons à ce domaine dans le présent document au sein duquel nous nous focaliserons sur la notion de XML part).

Comment cela fonctionne-t-il ?

Jetons un œil à la façon donc fonctionnent les XML parts customisés en commençant par le commencement. Nous allons télécharger une instance typique de données XML depuis un site Web public et l’inclure dans un document Open XML et démontrer quelques-unes des choses que l’architecture d’Open XML permet.

Pour cela, et à fin d’exemple, nous avons effectué une recherche sur le Web sur la chaîne de caractères « XML instance sample » et trouvé la page suivante : http://exchangenetwork.net/schema/WQX/1/WQX_XMLExample_v1.0.xml. C’est un exemple de document XML utilisé par « Exchange Network », un organisme qui aide les Etats américains et l’agence américaine de protection de l’environnement à échanger des informations ; nous allons utiliser ce document pour constituer nos données d’exemple.

Un des concepts clé du support des schémas customisés par Open XML est le fait que l’on peut utiliser n’importe quel schéma et n’importe quelle instance XML ce qui signifie que la source de ces données XML et la façon dont elles sont structurées n’ont aucune importance. Ce qui va être démontré dans la suite s’applique donc à n’importe quel fichier XML convenablement formé. Cet exemple a été choisi car il est plus compliqué que la plupart des exemples que l’on peut trouver sur le Web et qu’il constitue donc une approche à peu près réaliste d’un document XML. Voici un aperçu de ce qu’il contient :

samplexml.jpg

Sauvegardons ce fichier XML en un fichier appelé item1.xml, que nous allons intégrer au sein d’un document Open XML sous la forme d’un XML part customisé et le faire correspondre à quelques content controls.

Ajouter un XML part customisé à un document

On doit d’abord placer les données au sein d’un document Open XML sous le forme d’un XML part customisép. Ceci nécessite un peu d’édition, ce que l’on peut faire avec Notepad et le support des fichiers ZIP qui est offert en standard avec Windows Vista. Si l’on utilise un autre environnement, il est possible d’utiliser n’importe que éditeur de texte et n’importe quel outil permettant de décompresser un fichier ZIP.

Voici les étapes concernées :

  1. Créer un fichier de traitement de texte Open XML. Ceci peut être obtenu en tapant quelques mots au sein de Word 2007 et en sauvegardant ce contenu au format par défaut sous le nom de fichier sample.docx.

  2. Renommer ce document en .ZIP et placer une copie des données XML (item1.xml) dans un répertoire appelé customXml au sein du package ZIP.

  3. Ajouter la ligne suivante à la partie relations (document.xml.rels) dans le répertoire word\_rels :

    <Relationship Id="myCustomXmlRelationship"
    Type="https://schemas.openxmlformats.org/officeDocument/2006/relationships/customXml"
    Target="../customXml/item1.xml" />

  4. Renommer le document à nouveau en .DOCX.

Nous avons maintenant un document qui contient un XML part customisép. Nous ne renterons pas ici dans tous les détails afin de garder à l’exemple sa qualité de simplicité.

Si l’on ouvre ce document (sample.docx) avec Word 2007, qu’on le modifie et qu’on le sauvegarde, le XML part customisép fait partie du document mais on ne le voit pas dans l’interface homme – machine de Word car on n’a pas encore choisi d’exposer de quelque manière que ce soit les données métier qu’il contient maintenant. Mais Word suit les règles des spécifications Open XML ce qui fait que lorsqu’il sauvegarde un document, il a maintenant réalisé un certain nombre de choses automatiquement :

  • Il a créé un custom XML properties part  pour chacun des éléments XML customisés, appelé itemProps1.xml dans le répertoire customXml.
  • Il a ajouté une référence de schéma vers le custom XML properties part, indiquant le schéma pour les données métier considérées.
  • Il a affecté un GUID au XML part customisép, qui est également stocké dans le custom XML properties part. Ceci est très important car ce GUID sera utilise pour identifier de manière unique le XML part customisép quand on fera correspondre les éléments de présentation aux nœuds XML des données métier.
  • Word aime aussi énumérer les relations sous la forme rId1, rId2, etc. et a donc renommé myCustomXmlRelationship en rId1 ou quelque-chose d’approchant. Les identifiants de relations n’ont pas d’importance ici car il s’agit d’une relation implicite (il faut garder à l’esprit qu’il n’y a encore rien dans le corps du document qui fasse référence au XML part customisé.

Voici le contenu du fichier itemProps1.xml du document d’exemple que l’on a créé :

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<ds:datastoreItem ds:itemID="{548E2E51-45D3-44E4-8845-1542F6638E2D}"
xmlns:ds="https://schemas.openxmlformats.org/officeDocument/2006/customXml">
    <ds:schemaRefs>
        <ds:schemaRef ds:uri="http://www.exchangenetwork.net/schema/wqx/1"/>
    </ds:schemaRefs>
</ds:datastoreItem> 

Notre XML part customisé est maintenant inclus dans le document et tous les détails nécessaires sont en place au sein du document afin d’assurer que ce part restera intact au travers des différentes éditions. Ceci est utile pour de nombreux scénarios – par exemple la société Mindjet utilise cette technique pour inclure ses propre schémas propriétaires au sein d’un document Open XML et permettre ainsi une interopérabilité par aller et retour avec Word. Un consommateur de document Open XML (Word par exemple) peut complètement ignorer ces XML parts customisés et il n’y a rien dans le corps du document qui y fasse référence, de telle façon qu’il n’y ait aucun impact sur la logique de rendu ou de présentation.

Ajout de balises de structuration de document et mise en correspondance des données

Ensuite, il nous faut exposer les données métier au sein du document lui-même. Cette opération est facile à faire : on peut exposer les nœuds de ses données métier en utilisant une correspondance dans les deux sens qui permet à l’utilisateur d’éditer les données métier dans le document lui-même.

L’étape suivant consiste à ajouter quelques balises dans le document structuré. Pour cela on utilise l’onglet « Developer » (qu’il faut mettre en service sous les options de Word si cet onglet n’est pas affiché dans le « Ruban » puisque cette option est hors service par défaut – cf. plus haut). Ici, on a créé une table et entré du texte dans la colonne de gauche (décrivant ainsi quelques nœuds XML que l’on a sélectionné au hasard depuis nos données d’exemple) et ensuite inséré un simple contrôle de contenu textuel (c’est-à-dire une balise de document structuré) dans la colonne de droite pour chaque ligne :

addingsdts.jpg

L’étape suivante consiste à sauvegarder ce document et à ajouter l’élément de mise en correspondance des données qui connecte chaque balise du document structuré à un nœud du XML part customisé. Si l’on veut entrer dans les détails, il est possible d’examiner le document disponible ici.

L’élément y est appelé dataBinding et se trouve dans la section sdt properties. Voici, par exemple, l’élément inséré pour faire correspondre le premier contrôle de contenu à un nœud du XML part customisép :

<w:dataBinding 
w:prefixMappings="xmlns:ns0='http://www.exchangenetwork.net/schema/wqx/1'" 
w:xpath="/ns0:WQX[1]/ns0:Organization[1]/ns0:OrganizationDescription[1]/ns0:OrganizationFormalName" 
w:storeItemID="{548E2E51-45D3-44E4-8845-1542F6638E2D}" />

Il faut noter que cet élément spécifie trois choses :

  1. Le schéma associé avec le XML part customisé.
  2. L’expression XPath qui pointe vers le nœud que l’on fait correspondre dans le XML part customisép.
  3. Le GUID qui identifie le XML part customisép (il peut y avoir plusieurs XML part customisés dans un seul document si nécessaire).

Typiquement, on doit écrire ces éléments dataBinding dans le document à partir du code de son logiciel métier (dans cet exemple, ceci a été réalisé à l’aide de Notepad, mais cela reste un peu délicat). Une bonne solution pour ajouter des mises en correspondances est d’utiliser le Content Control Toolkit qui est disponible en téléchargement gratuit depuis Codeplex.

databound.jpg

Maintenant, on dispose d’un document lié aux données avec une mise en correspondance bidirectionnelle entre les éléments de présentation du document (les content controls) et les nœuds du XML part customisép. Ce document fournit un « frontal » pour les données métier qui sont ainsi exposées de telle façon que lorsqu’un utilisateur change une valeur dans un content control, le nœud correspondant au sein des données métier est mis à jour. Réciproquement, les développeurs peuvent facilement remplacer le XML part customisép (avec n’importe quel environnement qui supporte les packages ZIP – il n’y a aucun balisage Open XML nécessaire) et ainsi peupler le document avec de nouvelles données.

L’utilisateur peut modifier l’apparence du document comme il le désire, indépendamment de l’architecture de mise en correspondance des données car ce document dispose d’une véritable séparation entre la présentation et les données : il n’y a aucune balise Open XML dans le XML part customisé et aucune balise non Open XML dans le corps du document. Tout ceci peut être réalisé avec n’importe quel fichier XML, en provenance de n’importe quelle source en utilisant n’importe quel schéma (ou par de schéma du tout – en fait, le schéma est optionnel et n’est pas nécessaire pour réaliser ce qui est effectué ici).

Afin de clarifier l’ensemble des notions que l’on vient de parcourir, le schéma ci-dessous résume l’architecture générique d’un document Open XML :

Conclusions

Ce que nous venons d’évoquer plus haut représente un aperçu rapide de la puissance des XML parts customisés au sein des documents Open XML. L’exemple que l’on a utilisé pour illustrer ces fonctionnalités avait pour but essentiel de démonter que Open XML peut travailler avec l’importe quel schéma, y compris les schémas métier déjà utilisés dans les entreprises et tous ceux qui pourront y être développés dans le futur.

Une telle approche est de nature à favoriser l’interopérabilité verticale que l’on a définie ci-dessus afin de répondre aux besoins croissants des entreprises d’utiliser des formats de fichiers centrés sur les données contenues dans ces documents afin de pouvoir leur faire jouer un rôle plein et entier au sein des processus métier de l’entreprise.