Serveur d'exploration sur l'opéra

Attention, ce site est en cours de développement !
Attention, site généré par des moyens informatiques à partir de corpus bruts.
Les informations ne sont donc pas validées.

XML to the desktop

Identifieur interne : 000E62 ( Istex/Corpus ); précédent : 000E61; suivant : 000E63

XML to the desktop

Auteurs : Judith Wusteman

Source :

RBID : ISTEX:C8F0015B9303BBC98FAA675A2CCE208DB7F1C30D

Abstract

Now that XML is five years old, is it time for elibraries to start exploiting its full potential by delivering it to the end user rather than converting it to HTML first What, if any, would be the advantages to users and providers Could browsers cope And is it worth the bother

Url:
DOI: 10.1108/07378830310479875

Links to Exploration step

ISTEX:C8F0015B9303BBC98FAA675A2CCE208DB7F1C30D

Le document en format XML

<record>
<TEI wicri:istexFullTextTei="biblStruct">
<teiHeader>
<fileDesc>
<titleStmt>
<title xml:lang="en">XML to the desktop</title>
<author wicri:is="90%">
<name sortKey="Wusteman, Judith" sort="Wusteman, Judith" uniqKey="Wusteman J" first="Judith" last="Wusteman">Judith Wusteman</name>
<affiliation>
<mods:affiliation>Department of Library and Information Studies at University College Dublin, Ireland.</mods:affiliation>
</affiliation>
</author>
</titleStmt>
<publicationStmt>
<idno type="wicri:source">ISTEX</idno>
<idno type="RBID">ISTEX:C8F0015B9303BBC98FAA675A2CCE208DB7F1C30D</idno>
<date when="2003" year="2003">2003</date>
<idno type="doi">10.1108/07378830310479875</idno>
<idno type="url">https://api.istex.fr/document/C8F0015B9303BBC98FAA675A2CCE208DB7F1C30D/fulltext/pdf</idno>
<idno type="wicri:Area/Istex/Corpus">000E62</idno>
</publicationStmt>
<sourceDesc>
<biblStruct>
<analytic>
<title level="a" type="main" xml:lang="en">XML to the desktop</title>
<author wicri:is="90%">
<name sortKey="Wusteman, Judith" sort="Wusteman, Judith" uniqKey="Wusteman J" first="Judith" last="Wusteman">Judith Wusteman</name>
<affiliation>
<mods:affiliation>Department of Library and Information Studies at University College Dublin, Ireland.</mods:affiliation>
</affiliation>
</author>
</analytic>
<monogr></monogr>
<series>
<title level="j">Library Hi Tech</title>
<idno type="ISSN">0737-8831</idno>
<imprint>
<publisher>MCB UP Ltd</publisher>
<date type="published" when="2003-06-01">2003-06-01</date>
<biblScope unit="volume">21</biblScope>
<biblScope unit="issue">2</biblScope>
<biblScope unit="page" from="238">238</biblScope>
<biblScope unit="page" to="245">245</biblScope>
</imprint>
<idno type="ISSN">0737-8831</idno>
</series>
<idno type="istex">C8F0015B9303BBC98FAA675A2CCE208DB7F1C30D</idno>
<idno type="DOI">10.1108/07378830310479875</idno>
<idno type="filenameID">2380210213</idno>
<idno type="original-pdf">2380210213.pdf</idno>
<idno type="href">07378830310479875.pdf</idno>
</biblStruct>
</sourceDesc>
<seriesStmt>
<idno type="ISSN">0737-8831</idno>
</seriesStmt>
</fileDesc>
<profileDesc>
<textClass></textClass>
<langUsage>
<language ident="en">en</language>
</langUsage>
</profileDesc>
</teiHeader>
<front>
<div type="abstract" xml:lang="en">Now that XML is five years old, is it time for elibraries to start exploiting its full potential by delivering it to the end user rather than converting it to HTML first What, if any, would be the advantages to users and providers Could browsers cope And is it worth the bother</div>
</front>
</TEI>
<istex>
<corpusName>emerald</corpusName>
<author>
<json:item>
<name>Judith Wusteman</name>
<affiliations>
<json:string>Department of Library and Information Studies at University College Dublin, Ireland.</json:string>
</affiliations>
</json:item>
</author>
<subject>
<json:item>
<lang>
<json:string>eng</json:string>
</lang>
<value>Information retrieval</value>
</json:item>
<json:item>
<lang>
<json:string>eng</json:string>
</lang>
<value>Libraries</value>
</json:item>
<json:item>
<lang>
<json:string>eng</json:string>
</lang>
<value>Digital documents</value>
</json:item>
<json:item>
<lang>
<json:string>eng</json:string>
</lang>
<value>Document delivery</value>
</json:item>
</subject>
<language>
<json:string>eng</json:string>
</language>
<abstract>Now that XML is five years old, is it time for elibraries to start exploiting its full potential by delivering it to the end user rather than converting it to HTML first What, if any, would be the advantages to users and providers Could browsers cope And is it worth the bother</abstract>
<qualityIndicators>
<score>4.197</score>
<pdfVersion>1.2</pdfVersion>
<pdfPageSize>610 x 789 pts</pdfPageSize>
<refBibsNative>true</refBibsNative>
<keywordCount>4</keywordCount>
<abstractCharCount>277</abstractCharCount>
<pdfWordCount>3573</pdfWordCount>
<pdfCharCount>22062</pdfCharCount>
<pdfPageCount>8</pdfPageCount>
<abstractWordCount>52</abstractWordCount>
</qualityIndicators>
<title>XML to the desktop</title>
<genre>
<json:string>research-article</json:string>
</genre>
<host>
<volume>21</volume>
<pages>
<last>245</last>
<first>238</first>
</pages>
<issn>
<json:string>0737-8831</json:string>
</issn>
<issue>2</issue>
<subject>
<json:item>
<value>Information & knowledge management</value>
</json:item>
<json:item>
<value>Information & communications technology</value>
</json:item>
<json:item>
<value>Internet</value>
</json:item>
<json:item>
<value>Library & information science</value>
</json:item>
<json:item>
<value>Information behaviour & retrieval</value>
</json:item>
<json:item>
<value>Librarianship/library management</value>
</json:item>
<json:item>
<value>Information user studies</value>
</json:item>
<json:item>
<value>Metadata</value>
</json:item>
<json:item>
<value>Library technology</value>
</json:item>
</subject>
<genre>
<json:string>journal</json:string>
</genre>
<language>
<json:string>unknown</json:string>
</language>
<title>Library Hi Tech</title>
<doi>
<json:string>10.1108/lht</json:string>
</doi>
</host>
<publicationDate>2003</publicationDate>
<copyrightDate>2003</copyrightDate>
<doi>
<json:string>10.1108/07378830310479875</json:string>
</doi>
<id>C8F0015B9303BBC98FAA675A2CCE208DB7F1C30D</id>
<fulltext>
<json:item>
<original>true</original>
<mimetype>application/pdf</mimetype>
<extension>pdf</extension>
<uri>https://api.istex.fr/document/C8F0015B9303BBC98FAA675A2CCE208DB7F1C30D/fulltext/pdf</uri>
</json:item>
<json:item>
<original>false</original>
<mimetype>application/zip</mimetype>
<extension>zip</extension>
<uri>https://api.istex.fr/document/C8F0015B9303BBC98FAA675A2CCE208DB7F1C30D/fulltext/zip</uri>
</json:item>
<istex:fulltextTEI uri="https://api.istex.fr/document/C8F0015B9303BBC98FAA675A2CCE208DB7F1C30D/fulltext/tei">
<teiHeader>
<fileDesc>
<titleStmt>
<title level="a" type="main" xml:lang="en">XML to the desktop</title>
</titleStmt>
<publicationStmt>
<authority>ISTEX</authority>
<publisher>MCB UP Ltd</publisher>
<availability>
<p>EMERALD</p>
</availability>
<date>2003</date>
</publicationStmt>
<sourceDesc>
<biblStruct type="inbook">
<analytic>
<title level="a" type="main" xml:lang="en">XML to the desktop</title>
<author>
<persName>
<forename type="first">Judith</forename>
<surname>Wusteman</surname>
</persName>
<affiliation>Department of Library and Information Studies at University College Dublin, Ireland.</affiliation>
</author>
</analytic>
<monogr>
<title level="j">Library Hi Tech</title>
<idno type="pISSN">0737-8831</idno>
<idno type="DOI">10.1108/lht</idno>
<imprint>
<publisher>MCB UP Ltd</publisher>
<date type="published" when="2003-06-01"></date>
<biblScope unit="volume">21</biblScope>
<biblScope unit="issue">2</biblScope>
<biblScope unit="page" from="238">238</biblScope>
<biblScope unit="page" to="245">245</biblScope>
</imprint>
</monogr>
<idno type="istex">C8F0015B9303BBC98FAA675A2CCE208DB7F1C30D</idno>
<idno type="DOI">10.1108/07378830310479875</idno>
<idno type="filenameID">2380210213</idno>
<idno type="original-pdf">2380210213.pdf</idno>
<idno type="href">07378830310479875.pdf</idno>
</biblStruct>
</sourceDesc>
</fileDesc>
<profileDesc>
<creation>
<date>2003</date>
</creation>
<langUsage>
<language ident="en">en</language>
</langUsage>
<abstract xml:lang="en">
<p>Now that XML is five years old, is it time for elibraries to start exploiting its full potential by delivering it to the end user rather than converting it to HTML first What, if any, would be the advantages to users and providers Could browsers cope And is it worth the bother</p>
</abstract>
<textClass>
<keywords scheme="keyword">
<list>
<head>Keywords</head>
<item>
<term>Information retrieval</term>
</item>
<item>
<term>Libraries</term>
</item>
<item>
<term>Digital documents</term>
</item>
<item>
<term>Document delivery</term>
</item>
</list>
</keywords>
</textClass>
<textClass>
<keywords scheme="Emerald Subject Group">
<list>
<label>cat-IKM</label>
<item>
<term>Information & knowledge management</term>
</item>
<label>cat-ICT</label>
<item>
<term>Information & communications technology</term>
</item>
<label>cat-INT</label>
<item>
<term>Internet</term>
</item>
</list>
</keywords>
</textClass>
<textClass>
<keywords scheme="Emerald Subject Group">
<list>
<label>cat-LISC</label>
<item>
<term>Library & information science</term>
</item>
<label>cat-IBRT</label>
<item>
<term>Information behaviour & retrieval</term>
</item>
<label>cat-LLM</label>
<item>
<term>Librarianship/library management</term>
</item>
<label>cat-IUS</label>
<item>
<term>Information user studies</term>
</item>
<label>cat-MTD</label>
<item>
<term>Metadata</term>
</item>
<label>cat-LTC</label>
<item>
<term>Library technology</term>
</item>
</list>
</keywords>
</textClass>
</profileDesc>
<revisionDesc>
<change when="2003-06-01">Published</change>
</revisionDesc>
</teiHeader>
</istex:fulltextTEI>
<json:item>
<original>false</original>
<mimetype>text/plain</mimetype>
<extension>txt</extension>
<uri>https://api.istex.fr/document/C8F0015B9303BBC98FAA675A2CCE208DB7F1C30D/fulltext/txt</uri>
</json:item>
</fulltext>
<metadata>
<istex:metadataXml wicri:clean="corpus emerald not found" wicri:toSee="no header">
<istex:xmlDeclaration>version="1.0" encoding="UTF-8"</istex:xmlDeclaration>
<istex:document><!-- Auto generated NISO JATS XML created by Atypon out of MCB DTD source files. Do Not Edit! -->
<article dtd-version="1.0" xml:lang="en" article-type="research-article">
<front>
<journal-meta>
<journal-id journal-id-type="publisher-id">lht</journal-id>
<journal-id journal-id-type="doi">10.1108/lht</journal-id>
<journal-title-group>
<journal-title>Library Hi Tech</journal-title>
</journal-title-group>
<issn pub-type="ppub">0737-8831</issn>
<publisher>
<publisher-name>MCB UP Ltd</publisher-name>
</publisher>
</journal-meta>
<article-meta>
<article-id pub-id-type="doi">10.1108/07378830310479875</article-id>
<article-id pub-id-type="original-pdf">2380210213.pdf</article-id>
<article-id pub-id-type="filename">2380210213</article-id>
<article-categories>
<subj-group subj-group-type="type-of-publication">
<compound-subject>
<compound-subject-part content-type="code">research-article</compound-subject-part>
<compound-subject-part content-type="label">Research paper</compound-subject-part>
</compound-subject>
</subj-group>
<subj-group subj-group-type="subject">
<compound-subject>
<compound-subject-part content-type="code">cat-IKM</compound-subject-part>
<compound-subject-part content-type="label">Information & knowledge management</compound-subject-part>
</compound-subject>
<subj-group>
<compound-subject>
<compound-subject-part content-type="code">cat-ICT</compound-subject-part>
<compound-subject-part content-type="label">Information & communications technology</compound-subject-part>
</compound-subject>
<subj-group>
<compound-subject>
<compound-subject-part content-type="code">cat-INT</compound-subject-part>
<compound-subject-part content-type="label">Internet</compound-subject-part>
</compound-subject>
</subj-group>
</subj-group>
</subj-group>
<subj-group subj-group-type="subject">
<compound-subject>
<compound-subject-part content-type="code">cat-LISC</compound-subject-part>
<compound-subject-part content-type="label">Library & information science</compound-subject-part>
</compound-subject>
<subj-group>
<compound-subject>
<compound-subject-part content-type="code">cat-IBRT</compound-subject-part>
<compound-subject-part content-type="label">Information behaviour & retrieval</compound-subject-part>
</compound-subject>
<subj-group>
<compound-subject>
<compound-subject-part content-type="code">cat-IUS</compound-subject-part>
<compound-subject-part content-type="label">Information user studies</compound-subject-part>
</compound-subject>
<compound-subject>
<compound-subject-part content-type="code">cat-MTD</compound-subject-part>
<compound-subject-part content-type="label">Metadata</compound-subject-part>
</compound-subject>
</subj-group>
</subj-group>
<subj-group>
<compound-subject>
<compound-subject-part content-type="code">cat-LLM</compound-subject-part>
<compound-subject-part content-type="label">Librarianship/library management</compound-subject-part>
</compound-subject>
<subj-group>
<compound-subject>
<compound-subject-part content-type="code">cat-LTC</compound-subject-part>
<compound-subject-part content-type="label">Library technology</compound-subject-part>
</compound-subject>
</subj-group>
</subj-group>
</subj-group>
</article-categories>
<title-group>
<article-title>XML to the desktop</article-title>
</title-group>
<contrib-group>
<contrib contrib-type="author">
<string-name>
<given-names>Judith</given-names>
<surname>Wusteman</surname>
</string-name>
<aff>Department of Library and Information Studies at University College Dublin, Ireland.</aff>
</contrib>
</contrib-group>
<pub-date pub-type="ppub">
<day>01</day>
<month>06</month>
<year>2003</year>
</pub-date>
<volume>21</volume>
<issue>2</issue>
<fpage>238</fpage>
<lpage>245</lpage>
<permissions>
<copyright-statement>© MCB UP Limited</copyright-statement>
<copyright-year>2003</copyright-year>
<license license-type="publisher">
<license-p></license-p>
</license>
</permissions>
<self-uri content-type="pdf" xlink:href="07378830310479875.pdf"></self-uri>
<abstract>
<p>Now that XML is five years old, is it time for e‐libraries to start exploiting its full potential by delivering it to the end user rather than converting it to HTML first? What, if any, would be the advantages to users and providers? Could browsers cope? And is it worth the bother?</p>
</abstract>
<kwd-group>
<kwd>Information retrieval</kwd>
<x>, </x>
<kwd>Libraries</kwd>
<x>, </x>
<kwd>Digital documents</kwd>
<x>, </x>
<kwd>Document delivery</kwd>
</kwd-group>
<custom-meta-group>
<custom-meta>
<meta-name>peer-reviewed</meta-name>
<meta-value>no</meta-value>
</custom-meta>
<custom-meta>
<meta-name>academic-content</meta-name>
<meta-value>yes</meta-value>
</custom-meta>
<custom-meta>
<meta-name>rightslink</meta-name>
<meta-value>included</meta-value>
</custom-meta>
</custom-meta-group>
</article-meta>
</front>
<body>
<sec>
<title>Have things changed?</title>
<p>Less than two years ago, Michael Seadle (2001) commented that; “end‐users on the Internet do not love XML yet”. Have things changed enough that library users might now welcome XML arriving at their desktops? Would it be advantageous for users if it did? And is there browser support to make this possible? Of course, in many areas, XML will have achieved its full potential only when it has disappeared into the pipework, when it is not obvious whether an application is actually using XML. There is a whole range of potential applications of XML to libraries for which the delivery of an XML file to the desktop would be irrelevant. But for those for which it could be relevant, is now the time to stop dumbing down to HTML and let the end‐user have the real thing?</p>
</sec>
<sec>
<title>Maintaining XML – but delivering something else</title>
<p>There are already many library‐related projects that are storing, processing and managing XML, some for the markup of full documents, some for metadata. But practically all of them are delivering something else, often HTML – or, if they are delivering XML, it is only in the form of XHTML.</p>
<p>The eScholarship initiative at the California Digital Library[1] has made 500 books available online in “fully searchable XML”, marked up using the Text Encoding Initiative (TEI) DTD. But the only XML display format enabled is XHTML. As with many projects, the XML is transformed on the fly at the server using XSLT stylesheets; the resulting XHTML is presented using CSS. Again, in common with many projects, the open source Apache Cocoon middleware[2] is used for this transformation.</p>
<p>The Lector Longinquus Latin texts project[3] at the Center for Electronic Texts in the Humanities (CETH) is using Cocoon in a similar way. The transformation to HTML is seen as a stop‐gap until XML becomes:</p>
<disp-quote>
<p>… the standard for Web delivery of structured information … in the near future.</p>
</disp-quote>
<p>But, Brian Hancock and his colleagues at CETH believe that:</p>
<disp-quote>
<p>… the near future isn’t quite here yet (Hancock, B. 2003, personal communication, 17 February).</p>
</disp-quote>
<p>CETH’s Michael Giarlo thinks that:</p>
<disp-quote>
<p>It’ll probably be another 2‐3 years … before directly served XML really gets the support it needs.</p>
</disp-quote>
<p>CETH logs indicate that many of their users access the project via “older browsers”. However, they have already begun to experiment with XML delivery; a sample XML text is made available which “renders well with Netscape 7.1 and Mozilla 1.0.1”[3].</p>
<p>One of the projects most concerned to explore the potential of XML in the e‐journal sphere was the UIUC (University of Illinois at Urbana/Champaign) Digital Library Testbed[4]. Again, dynamic conversion of XML to HTML on the server and display using CSS was chosen. For the duration of the project (1999‐2001), lack of “native XML support in commercial Web browsers”[5] hampered attempts at XML rendering.</p>
<p>Some projects do provide the option of XML delivery. The Oxford Text Archive[6], for example, offers delivery of some of its electronic texts, corpora and reference works in XML, marked up using the teixlite DTD, that is, the XML version of the TEI Lite DTD [7].</p>
<p>The examples so far all involve the use of XML to mark up full document texts as well as metadata. Other projects use XML to structure only metadata. Again, in most cases, the XML is largely invisible by the time the information arrives at the user’s desktop. There are many implementations of the Open Archives Initiative (OAI)[8], for example. The protocol it enables makes it possible to:</p>
<disp-quote>
<p>… query multiple databases over the Web and receive the results in XML (Banerjee, 2002).</p>
</disp-quote>
<p>But there are, as yet, few examples where those search results are not converted to HTML before viewing.</p>
<p>On the other hand, XML is one of several dissemination formats for MEDLINE bibliographic citation data[9]. The user can save real XML but, if they choose the “Display XML” option, the result displayed is actually in HTML. Here is a snippet of some fictitious results viewed via a browser using the “Display XML” option:</p>
<p></p>
<p>Wusteman</LastName></p>
<p>Judith C</ForeName></p>
<p>JC</Initials></p>
<p></Author></p>
<p>and what you see if you view the page source:</p>
<p></p>
<p>Wusteman</p>
<p> </LastName></p>
<p>Judith C</p>
<p> </ForeName></p>
<p>JC</Initials></p>
<p></Author></p>
<p>The latter is embedded in an HTML document.</p>
</sec>
<sec>
<title>XML support</title>
<p>At this point, I should clarify what I mean by “delivering XML to the desktop” – it is a bit of vague description. Obviously, transforming XML to HTML at the server does not count – but does transforming XML to HTML at the client count as XML delivery? I would say that it does only if the transformation process is initiated by the user and under their control so that they can choose to side‐step it and access the real XML if they wish. On a related issue, I would count browser display via plugins of XML applications such as CML, MathML, and SVG as constituting “delivery of XML to the desktop”, although native browser support would be preferable. The latter is beginning to emerge for SVG and MathML but is unlikely for CML. A “universal plug‐in architecture” for CML is a more realisable goal (Murray‐Rust, P. 2003, personal communication, 28 February).</p>
<p>So is delivery of XML to the desktop realistic? The answer to this question depends on several factors including what you are delivering and why. But the major factor has to be the level of XML support in browsers.</p>
<p>What I mean by “XML support” depends on the application in question. But I would suggest that it could require support for some or all of the following standards: XML, CSS, DOM, XSLT, XHTML, Namespaces, SVG, SMIL, XLink, MathML and SOAP.</p>
<p>It seems fair to assume that, to base a delivery system on the concept, XML browser support would have to be of an advanced nature. So what is “advanced XML support”? In
<xref ref-type="fig" rid="F_2380210213001">Figure 1</xref>
, I suggest my own – no doubt contentious – definition of levels of XML support from basic to advanced. I have also listed some of the more popular browsers, indicating what XML support they have and how it can be graded.</p>
</sec>
<sec>
<title>The browsers</title>
<p>The browsers listed in the table have been grouped into families:</p>
<sec>
<title>Internet Explorer</title>
<p>This family includes IE for Windows and the Mac, the current AOL for Windows and previous versions of AOL for the Mac.</p>
<p>IE 5.0[10] was the first widely‐used browser to provide “direct” support for XML display. In actual fact, it involves conversion to DHTML within the browser, using a Working Draft version of the XSLT standard and subsequent display with rather flaky CSS. But the resulting “coloured, syntax‐highlighted version of the XML document, with collapsible views”[11] helped many of us visualise what might be possible with XML delivery. IE 6.0[12] has far more advanced XML support, as Figure 1 details.</p>
</sec>
<sec>
<title>Mozilla</title>
<p>IE may have been first but the Mozilla family is the best in terms of support for both XML and other W3C standards. Family members include Netscape 6[13] and beyond, Mozilla[14], Phoenix[15], Galeon[16], Chimera[17], Epiphany (Dumbill, 2003) and DocZilla[18].</p>
</sec>
<sec>
<title>Opera</title>
<p>In 2000, Opera 5.0[19] was receiving:</p>
<disp-quote>
<p>… international acclaim from end‐users and the industry press for being faster, smaller and more standards‐compliant than other browsers[20].</p>
</disp-quote>
<p>Mozilla has caught up but Opera is still a browser to watch.</p>
</sec>
<sec>
<title>KHTML</title>
<p>The family based on the KHTML engine includes Apple Safari[21] for the Mac and Konqueror[22] for Linux and Unix. In February 2003, Café Con Leche[23] reported that Apple had posted a new beta of Safari:</p>
<disp-quote>
<p>… that can display XML pages with CSS style sheets in the browser for the first time. XSLT does not appear to be supported yet.</p>
</disp-quote>
<p>The reporter liked the interface innovations enough to predict:</p>
<disp-quote>
<p>… The long, dark domination of Internet Explorer may be finally coming to an end.</p>
</disp-quote>
<p>But then IE for the Mac has always been unacceptably slow. The irony is that Mac IE 5.0 has far better standards compliance than its Windows equivalent.</p>
</sec>
<sec>
<title>Experimental browsers</title>
<p>Both XSmiles[24] and the W3C testbed browser Amaya[25] have excellent and innovative support for XML but neither are widely used.</p>
<p>As Tim Bray has commented:</p>
<disp-quote>
<p>… the browser ecosystem is becoming an interesting place again[26].</p>
</disp-quote>
</sec>
</sec>
<sec>
<title>Who is using what?</title>
<p>A reading of Figure 1 would suggest that any of the following browsers has sufficiently advanced XML support to enable an acceptable level of XML delivery: Internet Explorer 6, Netscape 7.x, Mozilla 1.x, Opera 7, Amaya and XSmiles.</p>
<p>So should electronic libraries start to deliver XML now? Unfortunately, in answering this question, we must first look, not at the innovative features in Mozilla, but at the percentage of users for each browser.</p>
<p>The inaccuracy of browser usage statistics is legend; the figures vary widely between sources. Statistics relating to use of different Mozilla‐based browsers may be inaccurate as it can be difficult for statistics gatherers to distinguish between them. A further cause of inaccuracy can arise from Opera’s pragmatic habit of announcing to the server that it is actually Internet Explorer. No wonder different sources of statistics vary on actual percentages.</p>
<p>But they all agree that IE dominates the market, with Netscape and Mozilla trailing far behind. On 3 February 2003, OneStat.com[27] reported that more than 60 per cent of all users were using IE 6.0 and over 33 per cent were using versions 5.0 or 5.5. Microsoft’s “total global usage share” was put at 95.3, Mozilla’s total was 1.2 and that of Netscape Navigator was 2.9 per cent. The only browsers without XML support for which statistics were significant were Netscape 4.0 at 1.0 per cent and IE 4.0 at 0.9 per cent.</p>
<p>So, at the time of writing (3 February), over 61 per cent of users have advanced XML browser capabilities and almost 97 per cent have reasonable XML capability. In addition, users appear to be upgrading their browsers more quickly than ever before. In particular, the move from one version of IE to the next seems to be accelerating, with the number of IE 6.0 users increasing by percentage points every month. This is probably due, in part, to the long‐delayed arrival of Windows XP. But a fair number of Windows 98 users have also moved to IE 6.0. Even if some e‐library applications are attracting users with older browsers, the rate of change of browser use alone should point to advanced XML capabilities for the majority of users within a year.</p>
<p>As well as considering the statistics, we also need to ponder future plans and possibilities. Might Netscape win the march on IE again? It lost it largely due to the inordinate amount of time it took to replace a standards‐feeble Netscape 4 with an impressive Netscape 7. It is also worth pointing out that AOL plan to move to a Mozilla‐based product for Windows, bringing with it 35 million users.</p>
<p>The cynic might warn against the assumption that, as far as XML support in browsers goes, things can only get better. A market share of over 80 per cent can be dangerous; perhaps Microsoft will decide that it will start doing things its own way again to lock in its users.</p>
<p>And finally, are there any generalisations we can make about browsers used for library‐related applications? At one level, one would hope that the answer was No; everyone is a potential user of the “library without walls”. But some generalisations may be possible within more specific user groups. Would an engineering library’s users be more likely to run Mozilla and those of an art and design library run Mac browsers? Probably. And, if we are developing tools for use solely within libraries, such as kiosks or CD content delivery, we can simply choose the browser that has the required features. The Mac‐based iCab browser[28] may be a useful option in these circumstances; it includes a “kiosk mode” that can restrict user access to certain pages. Alternatively, Opera’s ability to run on less powerful hardware than its major competitors may be a deciding factor.</p>
<p>Of course, there will be some projects for which my definition of “advanced XML support” is inadequate; I do not claim that browser support makes XML delivery possible for all e‐library projects.</p>
<p>Support for chemistry, for example, is still inadequate. But I do think that there are many projects out there that could already be providing an XML delivery option.</p>
</sec>
<sec>
<title>Is it worth the bother?</title>
<p>But should we aim at XML as “the standard for Web delivery of structured information”[3]? Is it worth the bother? Roy Tennant of the eScholarship initiative thinks not:</p>
<disp-quote>
<p>In the early days of XML, I was of the opinion that before long Web browsers would be XML‐capable and we would be shipping all kinds of XML straight to the desktop. But now I don’t think that at all … it doesn’t make much sense to ship XML to the client (Tennant, R., 2003, personal communication, 27 February).</p>
</disp-quote>
<p>I would accept that, for some projects, the gains from XML delivery may not outweigh the work involved in providing it – at present. Ironically, this may be true for some aspects of STM journal publishing, one of the arenas in which XML delivery could offer the most exiting advances for author and reader. XML is widely used in the journal lifecycle but often:</p>
<disp-quote>
<p>… primarily to record formatting. It is devoid of useful scientific markup and is based on the publishers’ business model needs and not on the readers’ or authors’ requirements (Murray‐Rust, P., personal communication, 28 February 2003).</p>
</disp-quote>
<p>There would be little point in delivering that XML to the user; the answer here has to be to rethink what and how we are marking up.</p>
<p>But, in many projects, I would argue that XML delivery is already worth the bother. As Ron Gilmour (2001) has commented:</p>
<disp-quote>
<p>Web users will become dissatisfied with receiving HTML digests of research data. Providing data in the form of XML allows users to manipulate the data for themselves, whether with tools provided by the author or with those that they create themselves.</p>
</disp-quote>
<p>An increasing proportion of e‐library projects maintaining XML documents will do so using native XML databases that allow complex queries. This begs the question: why then would you want the results to be in XML? Among the answers to this would be if you wanted to combine your results with those of one or several other systems or with your own metadata.</p>
<p>XML delivery could also enable complex sorts on large XML documents without requiring reloading from the server. Imagine the scenario in which a user accesses the results of a major search query; the XML file contains, say, 350 bibliographic records and is half a megabyte in size. With it is delivered an XSLT stylesheet. The user decides to sort the file by author and chooses the appropriate option; the stylesheet is used to sort the file at the client. Now the user wants to sort the file by date. At the click of a button, she has triggered a Javascript which reruns the stylesheet for this alternative sort. If all of this were performed at the server, the entire transformed file would have to be delivered to the client every time[29]. To save even more loading, the stylesheet for a particular library system could be cached while the user was accessing the site.</p>
<p>User control over the display provided by delivery of XML plus XSLT stylesheets might be of particular interest to libraries looking to supply a consistent user experience across content aggregated from several suppliers. Customised printer‐friendly output would be just one advantage of this method. It could be argued that the advantages of such user control might be minimal; it could simply be a case of transforming XML to HTML at the client rather than at the server. But even here, there can be advantages, in this case to the document provider; the use of XSLT transformations on the server can consume a lot of processing power.</p>
<p>There are also size advantages; a complex mathematical expression or chemical molecule is likely to be much smaller if represented in MathML and CML respectively than a JPEG or a movie file. And metadata can often be more succinctly described in XML than HTML.</p>
<p>Peter Murray‐Rust (personal communication, 28 February 2003) believes that:</p>
<disp-quote>
<p>… there is a technical and moral imperative to make our data available in XML … 90 per cent or more of scientific information gets lost in the publication process.</p>
</disp-quote>
<p>And Miller (2000) comments that:</p>
<disp-quote>
<p>A search result in XML … has structure and functionality.</p>
</disp-quote>
<p>Allowing the user to manipulate data is certainly an attractive proposition, though one that not all providers of information would be happy about. Do you really want to make your XML source file, representing an encoded finding aid, a chemical compound, a mathematical expression or other experimental data or creative work, available to the end‐user in its entirety? Concerns over loss of data ownership might well surface. As David Ruddy comments in relation to EAD finding aids[30], sending the entire source file to the user:</p>
<disp-quote>
<p>… may raise document security issues, depending on whether your institution includes sensitive information in its EAD instances, such as processing notes or cost figures, or information about donors.</p>
</disp-quote>
<p>In this case, says Ruddy, one of the simplest methods of removing this information prior to publication is to convert to HTML at the server, either on the fly or in batch, “sending out only the information intended for public consumption”.</p>
<p>In a similar vein, Roy Tennant (2003, personal communication, 27 February) comments:</p>
<disp-quote>
<p>Our books exist as one XML file. That means we would be shipping, in many cases, over a megabyte of text to someone’s desktop simply to see the table of contents or a chapter.</p>
</disp-quote>
<p>But converting XML to HTML is not the only method of removing or selecting material; it should be reasonably straightforward to do this while still delivering XML. Indeed, as editor of a special issue of a journal, I recently received the following query from a potential author (Murray‐Rust, P., personal communication, 18 October 2002):</p>
<disp-quote>
<p>Do you practice what you preach? We would like to publish in XML … . We would supply different stylesheets so the article can be viewed in different ways – for example we can already filter the thesis to omit the experimental details, or extract only the analytical data, etc. It runs on any XML‐aware browser – MSIE, Amaya, Mozilla, etc.</p>
</disp-quote>
<p>Having checked with the managing editor, I had to say “Sorry, no”. And, to be fair, this would be the standard response from a journal publisher at present. But I would agree with Murray‐Rust (personal communication, 28 February 2003) when he worries that, without more pro‐activity on the part of the information community, we may well get “stuck into the publisher’s model” over the next few years.</p>
</sec>
<sec>
<title>Display XML but …</title>
<p>In 2001, EBSCOhost introduced full‐text article delivery in XML to end‐users[31]; in 2002, it abandoned this delivery format. At the time, only IE version 5.0 and above could take advantage of this feature and a critical mass of such browsers did not exist. In the first quarter of 2003, somewhere around 96 per cent of browser users have at least the XML capability of IE 5.0; over 63 per cent of these have more. Less than 2 per cent are using browsers with no XML capability at all. These figures point to viable XML delivery. But for what material?</p>
<p>Lack of robust and consistent XLink or XPointer support means that it is not yet time to convert entire Web sites to XML. There are work‐arounds for displaying links and images in some browsers. For example, Mozilla allows the use of the XHTML Namespace within a different XML application to enable links and images[32]. But this illustrates a caveat: basing e‐library systems on non‐standard components of any browser can cause legacy problems.</p>
<p>A related caveat is that it is better for systems to attempt detection of browser capability rather than browser version. When accessed via any browser other than IE, the pioneering EAD Finding Aids project at the Cornell Institute for Digital Collections[33] returns the message:</p>
<disp-quote>
<p>You’ve requested an XML document, but your browser is not XML capable. We’ve delivered an HTML version instead.</p>
</disp-quote>
<p>To be fair, this is an experimental system. A more significant illustration of the principle is the current spat between Microsoft and Opera. The latter alleges dishonest tactics on the part of Microsoft:</p>
<disp-quote>
<p>… to make Opera look like it is displaying pages improperly when people view MSN (Broersma, 2003).</p>
</disp-quote>
<p>In response, Opera have released a “Bork” edition of Opera 7 for Windows that behaves differently on just one Web site:</p>
<disp-quote>
<p>Users accessing the MSN site will see the page transformed into the language of the famous Swedish Chef from the Muppet Show[34].</p>
</disp-quote>
<p>Any system delivering XML needs to cater – in a standard way – for all the browsers that have a wide usage at present. If you want to find out what is possible with XML delivery, take a look at the latest version of Mozilla, Netscape, Opera, Amaya or XSmiles. But to determine the level of XML functionality that the majority of your users are likely to have by 2004, you need to look at IE 6.</p>
<p>Deliver XML? Yes but, for the time being, you’ll still have to cater for the minority of Web browsers with little or inadequate XML support.</p>
</sec>
<sec>
<title>Notes</title>
<list list-type="order">
<list-item>
<label>1. </label>
<p>1 eScholarship initiative:
<ext-link ext-link-type="uri" xlink:href="http://escholarship.cdlib.org/">http://escholarship.cdlib.org/</ext-link>
</p>
</list-item>
<list-item>
<label>2. </label>
<p>2 Apache Cocoon:
<ext-link ext-link-type="uri" xlink:href="http://xml.apache.org/cocoon/">http://xml.apache.org/cocoon/</ext-link>
</p>
</list-item>
<list-item>
<label>3. </label>
<p>3 Lector Longinquus: Latintexts XML Conversion Project:
<ext-link ext-link-type="uri" xlink:href="http://harvest.rutgers.edu/ceth/xml/">http://harvest.rutgers.edu/ceth/xml/</ext-link>
</p>
</list-item>
<list-item>
<label>4. </label>
<p>4 UIUC Digital Library Testbed:
<ext-link ext-link-type="uri" xlink:href="http://dli.grainger.uiuc.edu/idli/reports.htm">http://dli.grainger.uiuc.edu/idli/reports.htm</ext-link>
</p>
</list-item>
<list-item>
<label>5. </label>
<p>5 UIUC Digital Library Testbed Final Report:
<ext-link ext-link-type="uri" xlink:href="http://dli.grainger.uiuc.edu/idli/progress_reports/final_report.htm">http://dli.grainger.uiuc.edu/idli/progress_reports/final_ report.htm</ext-link>
</p>
</list-item>
<list-item>
<label>6. </label>
<p>6 The Oxford Text Archive:
<ext-link ext-link-type="uri" xlink:href="http://ota.ahds.ac.uk/">http://ota.ahds.ac.uk/</ext-link>
</p>
</list-item>
<list-item>
<label>7. </label>
<p>7 The Electronic Text Center Introduction to TEI and Guide to Document Preparation (David Seaman):
<ext-link ext-link-type="uri" xlink:href="http://etext.lib.virginia.edu/tei/uvatei.html">http://etext.lib.virginia.edu/tei/uvatei.html</ext-link>
</p>
</list-item>
<list-item>
<label>8. </label>
<p>8 Open Archives Initiative:
<ext-link ext-link-type="uri" xlink:href="http://www.openarchives.org/">http://www.openarchives.org/</ext-link>
</p>
</list-item>
<list-item>
<label>9. </label>
<p>9 NCBI PubMed:
<ext-link ext-link-type="uri" xlink:href="http://www.ncbi.nlm.nih.gov/entrez/query.fcgi">www.ncbi.nlm.nih.gov/entrez/query.fcgi</ext-link>
</p>
</list-item>
<list-item>
<label>10. </label>
<p>10 Cover Pages – Microsoft Support for XML:
<ext-link ext-link-type="uri" xlink:href="http://xml.coverpages.org/xmlMicrosoft.html">http://xml.coverpages.org/xmlMicrosoft.html</ext-link>
</p>
</list-item>
<list-item>
<label>11. </label>
<p>11 The XML FAQ (Editor Peter Flynn):
<ext-link ext-link-type="uri" xlink:href="http://www.ucc.ie/xml">www.ucc.ie/xml</ext-link>
</p>
</list-item>
<list-item>
<label>12. </label>
<p>12 Internet Explorer 6:
<ext-link ext-link-type="uri" xlink:href="http://www.microsoft.com/windows/ie/default.asp">www.microsoft.com/windows/ie/default.asp</ext-link>
</p>
</list-item>
<list-item>
<label>13. </label>
<p>13 Netscape Navigator:
<ext-link ext-link-type="uri" xlink:href="http://channels.netscape.com/ns/browsers/">http://channels.netscape.com/ns/browsers/</ext-link>
</p>
</list-item>
<list-item>
<label>14. </label>
<p>14 XML in Mozilla:
<ext-link ext-link-type="uri" xlink:href="http://www.mozilla.org/newlayout/xml/">www.mozilla.org/newlayout/xml/</ext-link>
</p>
</list-item>
<list-item>
<label>15. </label>
<p>15 Phoenix:
<ext-link ext-link-type="uri" xlink:href="http://www.mozilla.org/projects/phoenix/phoenix-release-notes.html">www.mozilla.org/projects/phoenix/phoenix‐release‐notes.html</ext-link>
</p>
</list-item>
<list-item>
<label>16. </label>
<p>16 Galeon:
<ext-link ext-link-type="uri" xlink:href="http://galeon.sourceforge.net/">http://galeon.sourceforge.net/</ext-link>
</p>
</list-item>
<list-item>
<label>17. </label>
<p>17 Chimera:
<ext-link ext-link-type="uri" xlink:href="http://www.mozilla.org/projects/chimera/">www.mozilla.org/projects/chimera/</ext-link>
</p>
</list-item>
<list-item>
<label>18. </label>
<p>18 DocZilla
<ext-link ext-link-type="uri" xlink:href="http://www.doczilla.com/">www.doczilla.com/</ext-link>
</p>
</list-item>
<list-item>
<label>19. </label>
<p>19 Opera:
<ext-link ext-link-type="uri" xlink:href="http://www.opera.com">www.opera.com</ext-link>
</p>
</list-item>
<list-item>
<label>20. </label>
<p>20 W3Schools.com, The Norwegian Opera:
<ext-link ext-link-type="uri" xlink:href="http://www.w3schools.com/browsers/browsers_opera.asp">www.w3schools.com/browsers/browsers_opera.asp</ext-link>
</p>
</list-item>
<list-item>
<label>21. </label>
<p>21 Apple Safari:
<ext-link ext-link-type="uri" xlink:href="http://www.apple.com/safari/">www.apple.com/safari/</ext-link>
</p>
</list-item>
<list-item>
<label>22. </label>
<p>22 Konqueror:
<ext-link ext-link-type="uri" xlink:href="http://www.konqueror.org/">www.konqueror.org/</ext-link>
</p>
</list-item>
<list-item>
<label>23. </label>
<p>23 Cafe con Leche XML News and Resources, 13 February 2003:
<ext-link ext-link-type="uri" xlink:href="http://www.ibiblio.org/xml/news2003.html">www.ibiblio.org/xml/news2003.html</ext-link>
</p>
</list-item>
<list-item>
<label>24. </label>
<p>24 X‐Smiles:
<ext-link ext-link-type="uri" xlink:href="http://www.xsmiles.org/">www.xsmiles.org/</ext-link>
</p>
</list-item>
<list-item>
<label>25. </label>
<p>25 Amaya:
<ext-link ext-link-type="uri" xlink:href="http://www.w3.org/Amaya/">www.w3.org/Amaya/</ext-link>
</p>
</list-item>
<list-item>
<label>26. </label>
<p>26 The Web Standards Project, Buzz Archive, January 2003:
<ext-link ext-link-type="uri" xlink:href="http://www.webstandards.org/buzz/archive/2003_01.html">www.webstandards.org/buzz/archive/2003_ 01.html</ext-link>
</p>
</list-item>
<list-item>
<label>27. </label>
<p>27 OneStat.com, 3 February 2003:
<ext-link ext-link-type="uri" xlink:href="http://www.onestat.com/html/aboutus_pressbox18.html">www.onestat.com/html/aboutus_pressbox18.html</ext-link>
</p>
</list-item>
<list-item>
<label>28. </label>
<p>28 iCab Internet Browser:
<ext-link ext-link-type="uri" xlink:href="http://www.icab.de/index.html">www.icab.de/index.html</ext-link>
</p>
</list-item>
<list-item>
<label>29. </label>
<p>29 Example illustrating saving of local transformations in Mozilla:
<ext-link ext-link-type="uri" xlink:href="http://www.mozilla.org/newlayout/xml/debugdemos/books/books.xml">www.mozilla.org/newlayout/xml/debugdemos/books/books.xml</ext-link>
</p>
</list-item>
<list-item>
<label>30. </label>
<p>30 EAD Help Pages – EAD in XML:
<ext-link ext-link-type="uri" xlink:href="http://www.iath.virginia.edu/ead/xml.html">www.iath.virginia.edu/ead/xml.html</ext-link>
</p>
</list-item>
<list-item>
<label>31. </label>
<p>31 EBSCO Press Release March 15 2001:
<ext-link ext-link-type="uri" xlink:href="http://www.uk.ebsco.com/home/whatsnew/ehost44.stm">www.uk.ebsco.com/home/whatsnew/ehost44.stm</ext-link>
</p>
</list-item>
<list-item>
<label>32. </label>
<p>32 Example illustrating use of XHTML (and XLink) in Mozilla for linking and images:
<ext-link ext-link-type="uri" xlink:href="http://www.mozilla.org/newlayout/xml/debugdemos/tocdemo/rights.xml">www.mozilla.org/newlayout/xml/debugdemos/tocdemo/rights.xml</ext-link>
</p>
</list-item>
<list-item>
<label>33. </label>
<p>33 Cornell Institute for Digital Collections: EAD/XML Finding Aids Project:
<ext-link ext-link-type="uri" xlink:href="http://cidc.library.cornell.edu/xml/">http://cidc.library.cornell.edu/xml/</ext-link>
</p>
</list-item>
<list-item>
<label>34. </label>
<p>34 Opera Press Releases: Opera releases “Bork” edition – The Swedish Chef Goes After Microsoft (14 February 2003):
<ext-link ext-link-type="uri" xlink:href="http://www.opera.com/pressreleases/en/2003/02/14/">www.opera.com/pressreleases/en/2003/02/14/</ext-link>
</p>
</list-item>
</list>
</sec>
<sec>
<fig position="float" id="F_2380210213001">
<label>
<bold>Figure 1
<x> </x>
</bold>
</label>
<caption>
<p>Some of the more common Web browsers and details of their XML support</p>
</caption>
<graphic xlink:href="2380210213001.tif"></graphic>
</fig>
</sec>
</body>
<back>
<ref-list>
<title>References</title>
<ref id="B1">
<mixed-citation>
<person-group person-group-type="author">
<string-name>
<surname>Banerjee</surname>
,
<given-names>K.</given-names>
</string-name>
</person-group>
(
<year>2002</year>
), “
<article-title>
<italic>How does XML help libraries?</italic>
</article-title>
”,
<source>
<italic>Computers in Libraries</italic>
</source>
, Vol.
<volume>22</volume>
No.
<issue>8</issue>
, September, available at:
<ext-link ext-link-type="uri" xlink:href="http://www.infotoday.com/cilmag/sep02/Banerjee.htm">www.infotoday.com/cilmag/sep02/Banerjee.htm</ext-link>
</mixed-citation>
</ref>
<ref id="B2">
<mixed-citation>
<person-group person-group-type="author">
<string-name>
<surname>Broersma</surname>
,
<given-names>M.</given-names>
</string-name>
</person-group>
(
<year>2003</year>
), “
<article-title>
<italic>Opera ‘borks’ MSN in standards spat</italic>
</article-title>
”,
<source>
<italic>CNET News.com</italic>
</source>
, 14 February, available at:
<ext-link ext-link-type="uri" xlink:href="http://zdnet.com.com/2100-1104-984632.html">http://zdnet.com.com/2100‐1104‐984632.html</ext-link>
</mixed-citation>
</ref>
<ref id="B3">
<mixed-citation>
<person-group person-group-type="author">
<string-name>
<surname>Dumbill</surname>
,
<given-names>E.</given-names>
</string-name>
</person-group>
(
<year>2003</year>
), “
<article-title>
<italic>An epiphany in browsing</italic>
</article-title>
”,
<source>
<italic>WriteTheWeb</italic>
</source>
, 17 February 2003, available at:
<ext-link ext-link-type="uri" xlink:href="http://writetheweb.com/Members/edd/Articles/2003-02-epiphany">http://writetheweb.com/Members/edd/Articles/2003‐02‐epiphany</ext-link>
</mixed-citation>
</ref>
<ref id="B4">
<mixed-citation>
<person-group person-group-type="author">
<string-name>
<surname>Gilmour</surname>
,
<given-names>R.</given-names>
</string-name>
</person-group>
(
<year>2001</year>
), “
<article-title>
<italic>Serving XML: practical techniques for the dissemination of structured electronic information</italic>
</article-title>
”,
<source>
<italic>Library Hi Tech</italic>
</source>
, Vol.
<volume>19</volume>
No.
<issue>4</issue>
, pp.
<fpage>408</fpage>
<x></x>
<lpage>14</lpage>
.</mixed-citation>
</ref>
<ref id="B5">
<mixed-citation>
<person-group person-group-type="author">
<string-name>
<surname>Miller</surname>
,
<given-names>D.R.</given-names>
</string-name>
</person-group>
(
<year>2000</year>
), “
<article-title>
<italic>XML: libraries’ strategic opportunity</italic>
</article-title>
”,
<source>
<italic>netConnect, Library Journal</italic>
</source>
, Summer, available at:
<ext-link ext-link-type="uri" xlink:href="http://xmlmarc.stanford.edu/LJ/">http://xmlmarc.stanford.edu/LJ/</ext-link>
</mixed-citation>
</ref>
<ref id="B6">
<mixed-citation>
<person-group person-group-type="author">
<string-name>
<surname>Seadle</surname>
,
<given-names>M.</given-names>
</string-name>
</person-group>
(
<year>2001</year>
), “
<article-title>
<italic>A love affair with markup</italic>
</article-title>
”,
<source>
<italic>Library Hi Tech</italic>
</source>
, Vol.
<volume>19</volume>
No.
<issue>3</issue>
, pp.
<fpage>207</fpage>
<x></x>
<lpage>9</lpage>
.</mixed-citation>
</ref>
</ref-list>
</back>
</article>
</istex:document>
</istex:metadataXml>
<mods version="3.6">
<titleInfo lang="en">
<title>XML to the desktop</title>
</titleInfo>
<titleInfo type="alternative" lang="en" contentType="CDATA">
<title>XML to the desktop</title>
</titleInfo>
<name type="personal">
<namePart type="given">Judith</namePart>
<namePart type="family">Wusteman</namePart>
<affiliation>Department of Library and Information Studies at University College Dublin, Ireland.</affiliation>
</name>
<typeOfResource>text</typeOfResource>
<genre type="research-article" displayLabel="research-article"></genre>
<originInfo>
<publisher>MCB UP Ltd</publisher>
<dateIssued encoding="w3cdtf">2003-06-01</dateIssued>
<copyrightDate encoding="w3cdtf">2003</copyrightDate>
</originInfo>
<language>
<languageTerm type="code" authority="iso639-2b">eng</languageTerm>
<languageTerm type="code" authority="rfc3066">en</languageTerm>
</language>
<physicalDescription>
<internetMediaType>text/html</internetMediaType>
</physicalDescription>
<abstract lang="en">Now that XML is five years old, is it time for elibraries to start exploiting its full potential by delivering it to the end user rather than converting it to HTML first What, if any, would be the advantages to users and providers Could browsers cope And is it worth the bother</abstract>
<subject>
<genre>Keywords</genre>
<topic>Information retrieval</topic>
<topic>Libraries</topic>
<topic>Digital documents</topic>
<topic>Document delivery</topic>
</subject>
<relatedItem type="host">
<titleInfo>
<title>Library Hi Tech</title>
</titleInfo>
<genre type="Journal">journal</genre>
<subject>
<genre>Emerald Subject Group</genre>
<topic authority="SubjectCodesPrimary" authorityURI="cat-IKM">Information & knowledge management</topic>
<topic authority="SubjectCodesSecondary" authorityURI="cat-ICT">Information & communications technology</topic>
<topic authority="SubjectCodesSecondary" authorityURI="cat-INT">Internet</topic>
</subject>
<subject>
<genre>Emerald Subject Group</genre>
<topic authority="SubjectCodesPrimary" authorityURI="cat-LISC">Library & information science</topic>
<topic authority="SubjectCodesSecondary" authorityURI="cat-IBRT">Information behaviour & retrieval</topic>
<topic authority="SubjectCodesSecondary" authorityURI="cat-LLM">Librarianship/library management</topic>
<topic authority="SubjectCodesSecondary" authorityURI="cat-IUS">Information user studies</topic>
<topic authority="SubjectCodesSecondary" authorityURI="cat-MTD">Metadata</topic>
<topic authority="SubjectCodesSecondary" authorityURI="cat-LTC">Library technology</topic>
</subject>
<identifier type="ISSN">0737-8831</identifier>
<identifier type="PublisherID">lht</identifier>
<identifier type="DOI">10.1108/lht</identifier>
<part>
<date>2003</date>
<detail type="volume">
<caption>vol.</caption>
<number>21</number>
</detail>
<detail type="issue">
<caption>no.</caption>
<number>2</number>
</detail>
<extent unit="pages">
<start>238</start>
<end>245</end>
</extent>
</part>
</relatedItem>
<identifier type="istex">C8F0015B9303BBC98FAA675A2CCE208DB7F1C30D</identifier>
<identifier type="DOI">10.1108/07378830310479875</identifier>
<identifier type="filenameID">2380210213</identifier>
<identifier type="original-pdf">2380210213.pdf</identifier>
<identifier type="href">07378830310479875.pdf</identifier>
<accessCondition type="use and reproduction" contentType="copyright">© MCB UP Limited</accessCondition>
<recordInfo>
<recordContentSource>EMERALD</recordContentSource>
</recordInfo>
</mods>
</metadata>
<serie></serie>
</istex>
</record>

Pour manipuler ce document sous Unix (Dilib)

EXPLOR_STEP=$WICRI_ROOT/Wicri/Musique/explor/OperaV1/Data/Istex/Corpus
HfdSelect -h $EXPLOR_STEP/biblio.hfd -nk 000E62 | SxmlIndent | more

Ou

HfdSelect -h $EXPLOR_AREA/Data/Istex/Corpus/biblio.hfd -nk 000E62 | SxmlIndent | more

Pour mettre un lien sur cette page dans le réseau Wicri

{{Explor lien
   |wiki=    Wicri/Musique
   |area=    OperaV1
   |flux=    Istex
   |étape=   Corpus
   |type=    RBID
   |clé=     ISTEX:C8F0015B9303BBC98FAA675A2CCE208DB7F1C30D
   |texte=   XML to the desktop
}}

Wicri

This area was generated with Dilib version V0.6.21.
Data generation: Thu Apr 14 14:59:05 2016. Site generation: Thu Jan 4 23:09:23 2024