Open XML et les schémas métier - Deuxième partie - Formats de documents et interopérabilité sémantique
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.
La puissance d' Open XML réside dans le fait de supporter cette interopérabilité sémantique par le bias des schémas customisés. 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.
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.
Nous détaillerons dans le prochain épisode la mise en oeuvre des custom XML markup. A suivre...
Ce post vous a plu ? Ajoutez le dans vos favoris pour ne pas perdre de temps à le retrouver le jour où vous en aurez besoin :
