So says Alexander Johannesen in this excellent blog post. I wholeheartedly agree with him - I've never seen XML abused quite like this.

On the various mailing lists and blogs that cover the topic, you'll notice that it's fairly common practice to take the MARC/XML and parse it into some new format typically using X-Path/Query and/or regular expressions. It's also possible to use XSL to present the pure MARCXML without conversion -- BIBSYS has this interface -- but you can see that this approach is not without its limitations.

One of the drawbacks of the XSL approach is that you often want to present data in a way that is not compatible with the way data is formatted in MARC(XML); you might want to gather all the authors from the various fields they are represented in and present them together. XSL/T can do this, but it's often easier and possibly quicker to use X-Path/Query and/or regular expressions. Another related issue is that the structure of the MARC/XML you're parsing may not have the values you want to present in a (sub)field of their own, which leaves you with little choice but to use regular expressions on textual data.

I've been looking at this problem for a while now; from my own personal experience, the XML tools that are available leave something to be desired in terms of ease of use, functionality and speed, the structure in MARCXML -- as mentioned -- is often inadequate, and the framework you're working within may be best suited to using a different parsing method. Compounding this fact are issues like the library not having (the right) XML tools available, and programmers you're working with having their own preferences.

Mostly, you'll see MARCXML data being parsed into individual values before being converted into something else, be that XHTML or more perversely XML, and that it is this that is used as the basis of any presentation of content to end users. In many ways this is fair enough, but to my mind use of XSL(/T) (as with BIBSYS) is an elegant solution to this problem, though inviable in cases where the data structure is lacking.

These problems are widespread, and lead many solution providers to take shortcuts, massaging the data that you'd expect to be retrieving from MARCXML from sources like OpenURL ContextObjects or export formats meant for other applications. The reasons for this are, of course, speed, reliability and ease of use. Whether or not you feel comfortable extracting data from the non-definitive sources (which is what I consider these tertiary sources to be -- they're likely as not constructed from the MARCXML you're avoiding) is a matter of conscience, but, for me, it's odd that the data is there in MARCXML, but is unused.

Taking things at face value, we're in a situation that we've got good metadata, and we have a definitive source for this, but we can't use it for various reasons. How can this situation be remedied? For one, we need to express our concerns regarding structure in the unstructured parts of the XML we're receiving from metadata providers, secondly we need to build a proper toolset for this particular library application. It's all well and good building your one-off system, but we really need to merge our efforts, and provide multi-programming language packages that help us gather, for example, all the authors or owner data without having in-depth knowledge of a) MARCXML or b) the tool you're using to parse this data. In this way, you're providing a way of using MARCXML with a minimum of tricks, whether this be using regular expressions, XSL/T or X-Path/Query.

XML (Extensible markup language) est un langage de balisage générique dont le but est de permettre la fonctionnalité et l'interopérabilité du Web en permettant a plusieurs systèmes dinformation hétérogènes de communiquer et d'échanger. Autrement dit il repose sur des principes : c'est un langage de balisage extensible ; sa maintenance est assurée par le W3C ; les balises ne sont pas prédéfinies mais libres et précisent le sens ou la structure et non pas la présentation graphique (comme le fait HTML) ; le contenu, la structure et la présentation sont nettement dissociés ; la structure des informations est arborescente. 

Les raisons qui rendent intéressantes son utilisation sont que : c'est un format libre et ouvert ; il est indépendant de toute plateforme informatique ; il est promis à une certaine pérennité (il est répandu dans plusieurs domaines et bénéficie d'une solide structure de maintenance) ; il facilite l'interopérabilité. Pour de plus amples informations voir le dossier que j'avais indiqué sur un billet précédent. 

En bibliothèque son utilisation permet : d'afficher des notices bibliographiques sur le Web (MarcXML, MODS, BiblioML...) ; d'y échanger ces notices (OAI, Dublin Core...) ; d'y éditer des ressources (TEI, EAD...) ; d'y diffuser de l'information (RDF, RSS, Atom...). Pour mieux cerner les possibilités permises par XML, faisons une petite comparaison avec le format Marc que nous connaissons tous. Marc se matérialise sous la forme d'un format de saisie constitué de zones prédifinies et immuables, certaines de ces zones permettent de communiquer avec d'autres systèmes utilisant le même format ce qui permet à plusieurs bibliothèques d'échanger des notices bibliographiques par l'import ou l'export de celles-ci. Mais ces échanges ne concernent pas les usagers de nos bibliothèques qui sont dans l'impossibilité d'accéder aux notices via le Web (pour cela ils doivent préalablement passer par le site de la Bibliothèque pour accéder à son OPAC). Alors qu'avec XML, ces notices bibliographiques deviennent visibles à partir du Web parce qu'étant repérables par les différents outils de recherche qui le sillonnent. En d'autres termes nos OPAC sont mis en surface et accessibles, en principe, à tout internaute. Un autre avantage parmi d'autres est, par exemple, le changement de formats de notices de Marc à XML qui se fait sans perte de données, permettant ainsi une retroconversion "fidèle" de ces dernières... Ce souci de pallier l'incapacité du Marc à permettre les échanges sur le WEB,  sera à l'origine de la création du MarcXML par la Bibliothèque du Congrès en juin 2002. Je vous renvoie au billet N° 06 de ce blog où j'expose, dans la présentation en bas de page, les différentes insuffisances du format Marc face au Web et l'alternative offerte par les formats de métadonnées qui supportent, entre autres, un balisage en XML.

Cette visibilité de nos notices se manifeste aussi par l'utilisation des flux RSS, qui permettent de diffuser de l'information sous forme d'alerte. Un exemple tout simple est de créer un flux RSS de nouvelles acquisitions qui permet à tout utlisateur inscrit à ce flux d'être averti dès qu'il y a de nouvelles notices dans l'OPAC. Nous sommes là en présence d'un vraie application "bibliothèque 2.0", ce qui montre qu'XML mérite toute notre attention et qu'il serait judicieux de l'intégrer dans nos pratiques présentes et futures.

Prochainement, XML : initiation à la pratique