The Future of XML: How Will You Use XML in Years to Come?

Total Page:16

File Type:pdf, Size:1020Kb

The Future of XML: How Will You Use XML in Years to Come? The future of XML How will you use XML in years to come? Level: Intermediate Elliotte Rusty Harold ([email protected]), Adjunct Professor, Polytechnic University 05 Feb 2008 Elliotte Rusty Harold prognosticates what he thinks is in store for XML. The wheels of progress turn slowly, but turn they do. The crystal ball might be a little hazy, but the outline of XML's future is becoming clear. The exact time line is a tad uncertain, but where XML is going isn't. XML's future lies with the Web, and more specifically with Web publishing. It seems a little funny to have to say that. After all, isn't publishing what the Web is about? The Web was designed first and foremost as a mechanism to publish information. What else can it do? Quite a lot. The last three years have seen an explosion of interest in Web applications that go far beyond traditional Web sites. Word processors, spreadsheets, games, diagramming tools, and more are all migrating into the browser. This trend will only accelerate in the coming year as local storage in Web browsers makes it increasingly possible to work offline. But XML is still firmly grounded in Web 1.0 publishing, and that's still very important. Oneiromancy Several dreams are coming true this year. Sun's dream of network deployed applications is happening now, although shockingly the language of choice for these applications is JavaScript™, not Java™. This is a missed opportunity of the first order: Sun could have delivered this 10 years ago, but sadly it never had the experience, vision, or interest in the client to make it happen; now Sun is playing a desperate (and doomed) game of catch-up. Netscape's dream of replacing the operating system with a browser is also coming true this year. Netscape had the vision to see this coming. Unfortunately, it didn't have the business savvy or artistic taste necessary to pull it off. Nonetheless, Firefox and the Mozilla Foundation, both direct descendants of Netscape, are key players in bringing about this bold new world. For Microsoft®, the nightmare of a younger, nimbler competitor overtaking them is also coming true. The company was so distracted by Sun and Netscape that it failed to notice Google sneaking up on Office and Windows. GMail, Google Docs, and similar applications from a variety of sources are rapidly rendering the underlying operating system irrelevant. Sure, you still need an operating system to run a browser, but increasingly no one will care which operating system it is, any more than anyone in the last decade cared who manufactured their PC, as long as it ran Microsoft Windows®. Now no one will care who 1 From www.ibm.com/developerworks/xml/library/x-xml2008prevw.html1 3 February 2008 manufactures their operating system as long as it runs Google. Operating systems are being commodified, just as PCs were. The Windows monarch hasn't been defeated so much as abandoned, leaving Microsoft guarding the gates to an empty castle. What does XML have to do with this? For a much-hyped technology, XML has had little The evalJSon() option to do with this situation. Although the rebels sail under the Asynchronous JavaScript + XML (Ajax) banner, and although the x in Ajax stands for XML, Yes, I know about evalJSON(). no one uses XML much for any of this. Almost as Judging from some of the Ajax apps soon as the acronym was coined, Web developers I've seen, I'm more familiar with it than began replacing XML with raw JavaScript code and quite a few developers writing Ajax passing it around as data, and then executing it apps, who persist in using eval() years with eval() —security issues be damned. after better options became available. The problem is one of APIs, not data formats. More specifically, it's a problem with one API: Document Object Model (DOM). Most developers learn DOM first and then never learn any of the alternatives. They don't distinguish between DOM and XML, and thus they confuse their well-founded disgust with DOM with an unfounded disgust with XML. DOM isn't a least- common-denominator API: it's a worst-common-denominator API. You couldn't design a worse API for processing XML if you tried. But developers are extremely resistant to learning new things. Outside the Java community, where JDOM and dom4j have made some progress, better alternatives like E4X and the Amara XML Toolkit remain almost unknown and are actively resisted. The genius of JavaScript Serialized Object Notation (JSON) was also its biggest weakness. Because JSON is executable JavaScript code, it doesn't require JavaScript programmers to learn anything new to use it. A more secure data-transfer format wouldn't have been accepted. DOM is a millstone around XML's neck. It's the Frequently used acronyms single biggest impediment to broader XML adoption in software development. XML has • API: application programming gone as far as it can in programming while interface dragging this 2,000-pound boat anchor behind • HTML: Hypertext Markup it. Unless the World Wide Web Consortium Language (W3C) and browser vendors deprecate DOM • SGML: Standard Generalized and replace it with a sane alternative Markup Language (preferably several sane alternatives: trying to • W3C: World Wide Web do everything with one API is a large part of Consortium why DOM is as bad as it is), XML has run its • XML: Extensible Markup course in software development—especially Language Web software development (and increasingly, that's the only kind of software development that matters). The W3C should address the needs of working developers and deprecate a bad spec when required. Is XML dead? No, I believe that XML has a bright and important future. It just isn't a future that has much if anything to do with either classic or Web software 2 From www.ibm.com/developerworks/xml/library/x-xml2008prevw.html2 3 February 2008 development. To understand where XML is moving in 2008 and beyond, you have to first look back to 1997 and even earlier to find the origins of XML. The roots of XML You have to understand that XML was never meant to be used in software development—at least, not in the early days. None of the early specs—XML 1.0, XPath, Extensible Stylesheet Language Transformation (XSLT), Namespaces in XML, Extensible Hypertext Markup Language (XHTML), and DOM—focused on the needs of software developers. If XML had been designed for software development, it would have supported lists and maps and data types as JSON eventually did. XML was instead designed for publishing, and more specifically for publishing Web pages. XML was an outgrowth of a 20-year-older technology known as SGML. At roughly the same time Codd was at IBM® figuring out how to structure data by shredding it into tiny little unordered pieces, Charles F. Goldfarb, Edward Mosher, and Raymond Lorie were also at IBM figuring out how to structure large ordered documents that would never make sense as tables. Codd was thinking about business data like inventories and financial records. Goldfarb, Mosher, and Lorie were thinking about business documents like annual reports and airplane technical manuals. SGML was intended to solve publishing problems: how do you write, maintain, update, print, search, and read documents that may run to tens of thousands of pages across a variety of platforms with different processors, character sets, natural languages, operating systems, and vendors? SGML achieved some success with organizations in the government and military sectors that had these needs, and a few technical publishers like O'Reilly made occasional use of it; but overall it was too large and complex for most people's needs—even people in the publishing industry. SGML's biggest success was also its biggest failure: HTML. HTML was intended to be an SGML application, but almost none of the people who wrote browsers, editors, or Web pages knew anything about SGML beyond what the acronym stood for. (Many didn't even know that.) Extensions were introduced willy-nilly that rapidly degraded any claim HTML had to SGML conformance. Even the few and expensive SGML tools that then existed couldn't process the miasma of real-world HTML on the Web circa 1996. This was the situation XML was invented to rectify. On the one hand, it was supposed to simplify SGML down to one reasonable, standard subset everyone could agree on and faithfully implement. The hope was that this simpler specification could achieve the broader adoption that had eluded SGML. In this, XML mostly succeeded. On the other hand, XML was meant to lay the groundwork for a well-formed Web with fewer annoying cross-browser incompatibilities and idiosyncrasies In this, XML mostly failed. XML and XHTML just introduced yet another dialect of HTML that browsers would have to handle, without even coming close to replacing tag soup. Success or failure, XML was intended for publishing: books, manuals, and—most important— Web pages. XML wasn't optimized or planned for use in software development outside of publishing. Its use for config files, remote procedure calls, object serialization, database 3 From www.ibm.com/developerworks/xml/library/x-xml2008prevw.html3 3 February 2008 dumps, and similar developer-oriented tasks wasn't anticipated or planned for. Therefore it should come as little surprise that XML isn't always a perfect fit for these chores. Nonetheless, XML did offer developers something they never had before: a platform-independent, language- agnostic, internationally-savvy data format with numerous high-quality, free parsers easily available.
Recommended publications
  • Develop-21 9503 March 1995.Pdf
    develop E D I T O R I A L S T A F F T H I N G S T O K N O W C O N T A C T I N G U S Editor-in-Cheek Caroline Rose develop, The Apple Technical Feedback. Send editorial suggestions Managing Editor Toni Moccia Journal, a quarterly publication of or comments to Caroline Rose at Technical Buckstopper Dave Johnson Apple Computer’s Developer Press AppleLink CROSE, Internet group, is published in March, June, [email protected], or fax Bookmark CD Leader Alex Dosher September, and December. develop (408)974-6395. Send technical Able Assistants Meredith Best, Liz Hujsak articles and code have been reviewed questions about develop to Dave Our Boss Greg Joswiak for robustness by Apple engineers. Johnson at AppleLink JOHNSON.DK, His Boss Dennis Matthews Internet [email protected], CompuServe This issue’s CD. Subscription issues Review Board Pete “Luke” Alexander, Dave 75300,715, or fax (408)974-6395. Or of develop are accompanied by the Radcliffe, Jim Reekes, Bryan K. “Beaker” write to Caroline or Dave at Apple develop Bookmark CD. The Bookmark Ressler, Larry Rosenstein, Andy Shebanow, Computer, Inc., One Infinite Loop, CD contains a subset of the materials Gregg Williams M/S 303-4DP, Cupertino, CA 95014. on the monthly Developer CD Series, Contributing Editors Lorraine Anderson, which is available from APDA. Article submissions. Ask for our Steve Chernicoff, Toni Haskell, Judy Included on the CD are this issue and Author’s Guidelines and a submission Helfand, Cheryl Potter all back issues of develop along with the form at AppleLink DEVELOP, Indexer Marc Savage code that the articles describe.
    [Show full text]
  • XXX Format Assessment
    Digital Preservation Assessment: Date: 20/09/2016 Preservation Open Document Text (ODT) Format Team Preservation Assessment Version: 1.0 Open Document Text (ODT) Format Preservation Assessment Document History Date Version Author(s) Circulation 20/09/2016 1.0 Michael Day, Paul Wheatley External British Library Digital Preservation Team [email protected] This work is licensed under the Creative Commons Attribution 4.0 International License. Page 1 of 12 Digital Preservation Assessment: Date: 20/09/2016 Preservation Open Document Text (ODT) Format Team Preservation Assessment Version: 1.0 1. Introduction This document provides a high-level, non-collection specific assessment of the OpenDocument Text (ODT) file format with regard to preservation risks and the practicalities of preserving data in this format. The OpenDocument Format is based on the Extensible Markup Language (XML), so this assessment should be read in conjunction with the British Library’s generic format assessment of XML [1]. This assessment is one of a series of format reviews carried out by the British Library’s Digital Preservation Team. Some parts of this review have been based on format assessments undertaken by Paul Wheatley for Harvard University Library. An explanation of the criteria used in this assessment is provided in italics below each heading. [Text in italic font is taken (or adapted) from the Harvard University Library assessment] 1.1 Scope This document will primarily focus on the version of OpenDocument Text defined in OpenDocument Format (ODF) version 1.2, which was approved as ISO/IEC 26300-1:2015 by ISO/IEC JTC1/SC34 in June 2015 [2]. Note that this assessment considers format issues only, and does not explore other factors essential to a preservation planning exercise, such as collection specific characteristics, that should always be considered before implementing preservation actions.
    [Show full text]
  • Foxit Mobilepdf SDK Developer Guide
    Foxit MobilePDF SDK Developer Guide TABLE OF CONTENTS 1 Introduction to Foxit MobilePDF SDK ...........................................................................................1 1.1 Why Foxit MobilePDF SDK is your choice .............................................................................. 1 1.2 Foxit MobilePDF SDK .............................................................................................................. 2 1.3 Key features ........................................................................................................................... 3 1.4 Evaluation ............................................................................................................................... 5 1.5 License .................................................................................................................................... 5 1.6 About this Guide .................................................................................................................... 5 2 Getting Started ...........................................................................................................................7 2.1 Requirements ......................................................................................................................... 7 2.2 What is in the Package ........................................................................................................... 7 2.3 How to run a demo ...............................................................................................................
    [Show full text]
  • TP-1996-789.Pdf (141.1Kb)
    Nationaal Lucht- en Ruimtevaartlaboratorium National Aerospace Laboratory NLR NLR TP 96789 Overview and discussion of electronic exchange standards for technical information H. Kuiper and J.C. Donker DOCUMENT CONTROL SHEET ORIGINATOR'S REF. SECURITY CLASS. NLR TP 96789 U Unclassified ORIGINATOR National Aerospace Laboratory NLR, Amsterdam, The Netherlands TITLE Overview and discussion of electronic exchange standards for technical information PRESENTED AT the CALS Europe'96 conference, Paris, May 29-31, under the title "SGML, HTML, the paperless office... what about the forests and the trees", upon invitation of the NL MOD Representative in the conference committee. AUTHORS DATE pp ref H. Kuiper and J.C. Donker 960725 36 8 DESCRIPTORS Computer graphics Multimedia Document storage Software tools Document markup languages Standards Format Texts Hypertext Word processing Information dissemination ABSTRACT Nowadays more and more information is being exchanged electronically. Reasons for this include a higher degree of cooperation between information suppliers and users, an increasing demand for speed (of production and modification, and reduction of time to market), and cost reduction. On the technology side, the advent of the electronic highway enables effective and efficient electronic information exchange. For reasons of timeliness and life cycle costs, standards and specifications are becoming more important. The aim of this paper is to provide an overview of standards and specifications for electronic exchange of (technical document) information and to discuss the most common ones currently available for text, images, and document exchange. Emerging standards and specifications, such as for audio, video and virtual environments are also briefly discussed. Finally, a brief description is given of a standard for enterprise integration and product data exchange.
    [Show full text]
  • Nitro PDF Professional 5.X User Guide 2 Nitro PDF Professional User Guide
    Nitro PDF Professional 5.x User Guide 2 Nitro PDF Professional User Guide Table of Contents Part I START 7 Part II Help & Registration 7 1 Getting Started................................................................................................................................... guide 7 2 Online help................................................................................................................................... 7 3 Checking ...................................................................................................................................for software updates 8 4 Registering................................................................................................................................... product 8 Part III Workspace 8 1 Ribbon interface................................................................................................................................... 9 Hiding & showing the.......................................................................................................................................................... ribbon 10 Ribbon shortcuts .......................................................................................................................................................... 11 2 Quick Access................................................................................................................................... Toolbar 11 3 Nitro PDF..................................................................................................................................
    [Show full text]
  • Opendoc Spreadsheet Function File Date
    Opendoc Spreadsheet Function File Date Braless Ignacius fordid homologically. Is Sayre asthenic or unkindled after rock-bottom Olaf bosom so whacking? Solly compromising gymnastically as inward Ira flukes her releasers fraternized tacitly. The simple example will be used for use org requires extra buttons opendoc spreadsheet function file date entries from sql insertion. Depending on our security that describe presentation, an integer values of numbers, and a reference, store opendoc spreadsheet function file date, gives a really funny face when converting html. There are zeros if omitted, gnumeric can have existing session names in a text documents or a draw page. Yank subtree belonging to backup data management and attributes that is currently selected by using resources below opendoc spreadsheet function file date as word lists, as you could have. Each field form a few minutes open the width number of opendoc spreadsheet function file date used a cell cannot find any warranty disclaimers may overlap with a namespace and xforms model. The characters need to jpg image data according to. The currently visible or linked into exceptions must rest api offers different formats would be used for a packaging system along with two. The partition splits into your desktop version. Java works as timezone in jpg or reference returns an example, while they respect you? The first dereferenced, view it is explicitly defined in several instances, such a data pilot table of text is sometimes we will thus free. List for those that you need to grant patent licenses. Both versions might automatically terminate. This application opendoc spreadsheet function file date and quitting fellows and are unique address within a regular expression is stored there is automatic style.
    [Show full text]
  • 16-02-15 Willkie Buono
    CorporateThe Metropolitan Counsel® www.metrocorpcounsel.com Volume 16, No. 2 © 2008 The Metropolitan Corporate Counsel, Inc. February 2008 The Power Of Choice: Massachusetts Wisely Embraces Multiple Document Format Standards To Drive Greater Competition And Innovation Francis M. Buono closely than in Massachusetts. issued a report entitled “Open Standards, From the moment certain Massachusetts Closed Government: ITD’s Deliberate Disre- and McLean Sieverding government IT officials set in motion a plan to gard for Public Process,” in which it sharply mandate the use of the OpenDocument For- criticized the ITD for: (1) releasing the ETRM WILLKIE FARR & GALLAGHER LLP mat (“ODF”) as the default format for gov- despite public testimony that ODF may impair ernment documents, to the exclusion of other A “document format” (also known as a IT accessibility for thousands of workers with formats, the thorough and very public vetting “file format”) is a particular way to encode disabilities; (2) failing to conduct a cost analy- of the goals, potential impact, and resolution information for storage in a computer file.1 sis or develop implementation documents of the plan has caused many to question the Numerous document formats exist for encod- prior to issuing the ETRM; and (3) issuing appropriate role that government should play ing and storing the same type of information provisions in the ETRM relating to public in selecting and/or excluding technology solu- in word processing, spreadsheet, presentation, records management without the requisite tions (standards-based or otherwise), and on and other document types. Such document statutory authority.4 These shortcomings were what basis. Fortunately for Massachusetts and formats can complement each other by offer- its citizens, the goals of technical neutrality, later detailed in a comprehensive report by the ing different functionality, compete with one 5 choice, and inclusiveness prevailed, and other Auditor of the Commonwealth.
    [Show full text]
  • Automatic Digital Document Processing and Management
    Advances in Pattern Recognition For other titles published in this series, go to www.springer.com/series/4205 Stefano Ferilli Automatic Digital Document Processing and Management Problems, Algorithms and Techniques Stefano Ferilli Dipartimento di Informatica Università di Bari Via E. Orabona 4 70126 Bari Italy [email protected] Series Editor Professor Sameer Singh, PhD Research School of Informatics Loughborough University Loughborough UK ISSN 1617-7916 ISBN 978-0-85729-197-4 e-ISBN 978-0-85729-198-1 DOI 10.1007/978-0-85729-198-1 Springer London Dordrecht Heidelberg New York British Library Cataloguing in Publication Data A catalogue record for this book is available from the British Library © Springer-Verlag London Limited 2011 Apart from any fair dealing for the purposes of research or private study, or criticism or review, as per- mitted under the Copyright, Designs and Patents Act 1988, this publication may only be reproduced, stored or transmitted, in any form or by any means, with the prior permission in writing of the publish- ers, or in the case of reprographic reproduction in accordance with the terms of licenses issued by the Copyright Licensing Agency. Enquiries concerning reproduction outside those terms should be sent to the publishers. The use of registered names, trademarks, etc., in this publication does not imply, even in the absence of a specific statement, that such names are exempt from the relevant laws and regulations and therefore free for general use. The publisher makes no representation, express or implied, with regard to the accuracy of the information contained in this book and cannot accept any legal responsibility or liability for any errors or omissions that may be made.
    [Show full text]
  • Linux World News
    LINUX WORLD NEWS LINUX WORLD NEWS FIRST NEW ZEALAND OPEN SOURCE AWARD In October, more than 200 sion won the prize for “Open Additionally, the NZOSS honored people – among them the Source Use in Government,” and the work of the Open Polytechnic country’s Minister of Infor- the category “Open Source Use in and Michael Koziarski with two mation Technology, Hon. Business” went to Zoomin and Pro- special awards. David Cunliff – celebrated jectX for online mapping of New The jury of seven, convened the achievements of New Zealand. by Don Christie, the president Zealanders in the develop- New Zealand’s own “Summer of of NZOSS, had to choose from ment and use of open source Code” project received the prize in 34 finalists, the essence of more at the Intercontinental Hotel the category “Open Source Use in than 130 nominations. The in Wellington. The privately Education,” and the not-for-profit awards were presented for the sponsored “New Zealand VetLearn Foundation, which pro- first time. Open Source Award” was vides a successful Moodle portal http:// www. nzosa. org. nz/ presented in eight categories. for veterinarians, won the category http:// nzoss. org. nz/ Peter Harrison, the founder “Open Source Use for Community http:// nz. youtube. com/ and former president of the Organizations.” results?search_query=NZOSA07 New Zealand Open Source Society (NZOSS), went Another portal, Julian Oliver’s http:// www. gwprojects. org/ forum/ home with the title “Open Source Ambassador,” SelectParks, aimed at open source http:// www. e. govt. nz/ policy/ and Perlmonger Chris Cormack won the “Open game developers and artists, went open-source/ Source Contributor” category.
    [Show full text]
  • SAP Businessobjects Live Office User Guide ■ SAP Businessobjects Business Intelligence Platform 4.1 Support Package 2
    SAP BusinessObjects Live Office User Guide ■ SAP BusinessObjects Business Intelligence platform 4.1 Support Package 2 2013-11-21 Copyright © 2013 SAP AG or an SAP affiliate company. All rights reserved. No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior notice. Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors. National product specifications may vary. These materials are provided by SAP AG and its affiliated companies ("SAP Group") for informational purposes only, without representation or warranty of any kind, and SAP Group shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP Group products and services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty. SAP and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and other countries. Please see http://www.sap.com/corporate-en/legal/copyright/index.epx#trademark for additional trademark information and notices. 2013-11-21 Contents Chapter 1 About this document ..............................................................................................................7 1.1 Who should read this
    [Show full text]
  • MVP: Model-View-Presenter the Taligent Programming Model for C++ and Java
    (C) Copyright Taligent, Inc. 1996 - All Rights Reserved MVP: Model-View-Presenter The Taligent Programming Model for C++ and Java Mike Potel VP & CTO Taligent, Inc. Taligent, a wholly-owned subsidiary of IBM, is developing a next generation programming model for the C++ and Java programming languages, called Model-View-Presenter or MVP, based on a generalization of the classic MVC programming model of Smalltalk. MVP provides a powerful yet easy to understand design methodology for a broad range of application and component development tasks. Taligent’s framework-based implementation of these concepts adds great value to developer programs that employ MVP. MVP also is adaptable across multiple client/server and multi-tier application architectures. MVP will enable IBM to deliver a unified conceptual programming model across all its major object-oriented language environments. Smalltalk Programming Model The most familiar example of a programming model is the Model-View-Controller (MVC) model1 of Smalltalk developed at Xerox PARC in the late 1970’s. MVC is the fundamental design pattern used in Smalltalk for implementing graphical user interface (GUI) objects, and it has been reused and adopted to varying degrees in most other GUI class libraries and application frameworks since. Controller data gestures change & events notification Model View data access Smalltalk represents a GUI object such as a check box or text entry field using the three core abstractions of MVC. A model represents the data underlying the object, for example, the on-off state of a check box or the text string from a text entry field. The view accesses the data from the model and specifies how the data from the model is drawn on the screen, for example, an actual checked or unchecked check box, or a text entry box containing the string.
    [Show full text]
  • Portable Documents: Problems and (Partial) Solutions
    ELECTRONIC PUBLISHING, VOL. 8(4), 343±367 (MARCH 1996) Portable documents: problems and (partial) solutions DAVID W. BARRON Department of Electronics and Computer Science University of Southampton Southampton SO17 1BJ UK SUMMARY The paper presents a wide-ranging survey of the issues that arise in producing portable doc- uments, including multimedia and hypermedia documents. It is directed at practitioners, and the approach is therefore pragmatic, based on the current state of the art; the paper does not attempt to provide a comprehensive survey of all previous work on this topic. The nature of an electronic document is discussed,and the various kinds of portability that may be required are de®ned. Ways in which portability can be achieved in a variety of restricted contexts are presented,including approachesto portability based on international and de facto industry stan- dards. The likely success of the competing standards is assessed. Finally the paper addresses the question of whether complete document portability is achievable, or even necessary. KEY WORDS Portability, SGML, Standards, OpenDoc, ODA, HyTime 1 INTRODUCTION Corporate information is increasingly viewed, shared, distributed and managed electroni- cally ± a recent estimate [1] suggests that eighty percent of all corporate information today exists in digital form. Commercial publishers are moving towards CD-ROM as an alter- native to paper, especially for reference and entertainment publications, and the `digital library' is foreshadowed by the emergence of electronic versions of scienti®c journals and research papers. This move towards electronic documents highlights the need for portabil- ity of such documents over disparate hardware and software platforms, if the maximum bene®t is to be obtained from this new technology.
    [Show full text]