DOCSLIB.ORG

Appendix A: Introduction to XHTML

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

Appendix A: Introduction to XHTML HTML (HyperText Markup Language) is the authoring language created for the World Wide Web, to support the distribution of information over the Internet by means of Web pages. Authoring of an HTML document requires only a primitive text editor. To prepare a document for presentation to anyone in the world, it must be stored on a Web server which associates the document with an address and responds to page requests from software applications called Web clients or user agents . The user agent commonly used by humans for browsing the Web and for accessing resources is called a Web browser . An HTML document is a structured document consisting of three components: the HTML version information, the header , and the body . The header contains the title of the page and possibly some metadata. Web browsers usually show the title as the window title. The body includes the content intended to be displayed in the browser window as the Web page. The structure of the Web page is indicated by means of textual elements including headings at several levels, paragraphs, various types of lists, and tables. Multimedia features enable pages’ authors to include images, video clips, other HTML pages, and other objects in their pages. For exam- ple, a page may include interactivity provided by software applications called applets . The language includes hyperlinks (or links ) so that pages can be connected to each other and to other kinds of digital information resources. A link has a direction and two ends called anchors , a source anchor and a destination anchor. The example below creates two links: one from the document to the description of the p element in the HTML 4 specifi cation, another from the end of the document to the top of the same document. Element a is used both for the source and destination anchors. A. Salminen and F. Tompa, Communicating with XML, 207 DOI 10.1007/978-1-4614-0992-2, © Springer Science+Business Media, LLC 2011 208 Appendix A: Introduction to XHTML <html><head> <title>Simple html example</title></head> <body> <h3><a name="beginning">Example with two links</a></h3> <p> A paragraph on a Web page is delimited by the element <a href="http://www.w3.org/TR/html401/struct/text.html#h-9.3.1">p</a>.</p> <p><a href="#beginning">top</a></p> </body> </html> XHTML (Extensible HyperText Markup Language) provides the same capabili- ties as HTML 4, but instead of being an SGML application, XHTML is an XML application. This means that XHTML pages follow the rules of XML and may thus be processed using XML software. The XHTML 1.0 specifi cation defi nes three language variants, each correspond- ing to one of the three variants of HTML 4: Strict, Transitional, and Frameset. Strict is the variant that does not include styling capabilities but is instead based on the idea that the styling information is provided in style sheets. Strict is the variant that is recommended for most uses. Transitional includes style attributes to support leg- acy pages from browser environments, where style attributes were commonly used. The Frameset variant includes the description of frames. The example above could be a piece of markup in either an HTML or an XHTML document. However, HTML allows the same information to be provided in ways that are not accepted in XHTML. For example, the end-tags of the p ele- ments could be omitted and both upper case and lower case letters could be used in element and attribute names. In XHTML, like in all XML documents, all ele- ment and attribute names must be in lower case, and end-tags are required in all non-empty elements. An important feature in XHTML is that the specifi cation is modularized so that various XHTML languages can be defi ned from the standard building blocks for different types of devices. Thus XHTML is not a single language with three vari- ants, but instead a family of current and future languages and modules that reformu- late, subset, and extend HTML 4. The document XHTML Modularization defi nes sets of elements in modules so that arbitrary module combinations can be used, and probably extended, to defi ne XHTML conforming languages for various platforms. This is intended to enable easy exchange of data across platforms. The core modules must be present in any language considered to be a language in the XHTML family. These modules contain the basic structural and text elements, as well as the anchor element a enabling the creation of links. For example, all elements in the previous example are included in the core modules. In addition, special mod- ules are available for images, frames, forms, and scripting, among other features. As an example, XHTML 1.1 defi nes XHTML 1.0 Strict using modules. Alternatively, XHTML Basic is designed especially for small appliances, such as mobile phones, car navigation systems, and digital book readers, to replace the vari- ous HTML variants that have been designed for those devices. Appendix B: History of XML The history leading to the development of XML is summarized in Table B.1 , and some milestones in the development of XML are depicted in Table B.2 . The story behind these two tables is provided by the narrative in this appendix, which is divided into four parts: Origins of the Internet , Origins of SGML , From the Internet to the World Wide Web , and From SGML to XML . A list of historical readings, which have also served as our main information sources, can be found at the end of the appendix. B.1 Origins of the Internet Computer networking started in the United States in the 1960s, at the time of the Cold War. The Soviet Union’s success in launching Sputnik into space in the previous decade activated technological research and development in U.S. In 1958 the U.S. Department of Defense established a new organization called ARPA (the Advanced Research Projects Agency, which was subsequently called DARPA, the Defense Advanced Research Projects Agency) to support research on computer networking. The ARPANET network was created in 1969, interconnecting four computers at four universities by the end of that year. At fi rst ARPANET was used for fi le transfer and remote computing. To activate collaborative development of technical specifi cations, a practice called RFC (Request for Comments) was initiated. This practice was based on open publication of specifi cations and an open request for comments. Besides ARPANET, several other computer networks were developed in the 1970s. Their architectures and connection protocols differed from those of the ARPANET. The idea of “Internetworking Architecture,” a network of intercon- nected networks with various architectures, evolved. To implement this idea, a new transmission protocol was needed. TCP/IP (Transmission Control Protocol / Internet Protocol) was developed for this purpose, and it formed the underpinnings of today’s Internet. This activated wide interest in further development of network technologies in many countries. Because the researchers needed effective means of communication to support collaboration, electronic mail was created. 209 210 Appendix B: History of XML B.2 Origins of SGML Automated text processing of documents was well-established by the 1960s [20], and the problems with embedded formatting instructions were soon identifi ed. In a meeting of the Canadian Government Printing Offi ce in 1967, William Tunnicliffe pointed out the importance of separating information content in documents from their format. The idea of “generic document coding” was an important feature in the language Charles Goldfarb, Ed Mosher, and Ray Lorie designed at IBM. In his article in the ACM SIGPLAN/SIGOA conference in 1981, Charles Goldfarb adopted the term Generalized Markup Language (GML) for the language developed at IBM and the term descriptive markup for the document coding style in GML. In the same article Goldfarb emphasized the importance of rigorous markup if the processing of sets of documents of certain types were to be automated. The work towards standardized rules for descriptive markup started in a commit- tee of the International Organization for Standardization (ISO). The fi rst chair of the committee was William Tunnicliffe, and the concrete development work was done primarily by Charles Goldfarb. The work resulted in the Standard Generalized Markup Language (SGML), accepted as ISO standard 8879 in 1986. B.3 From the Internet to the World Wide Web Even though the U.S. Department of Defense was the principal force behind the Internet, the technical specifi cation documents were public and development work was open for university researchers worldwide. Therefore networking soon expanded to other countries. The World Wide Web (WWW) was introduced in 1991, and that same year the Internet Society was organized to coordinate the development of the Internet. WWW was a hypermedia application designed by Tim Berners-Lee and Robert Cailliau for CERN (the European Organization for Nuclear Research) to support collaboration among the physicists working around the world. The information published in the World Wide Web was accessible throughout the Internet via documents linked to each other by hyperlinks. The system was based on a client–server architecture and incorporated three major technological innovations: HTML (HyperText Markup Language) as the presentation language for documents and hyperlinks, HTTP (Hypertext Transfer Protocol) as the rules for exchanging documents between computers, and URI (Uniform Resource Identifi er) as the notation for identifying objects uniquely throughout the Internet. In 1992, more than one million computers were connected to the Internet. WWW proved to be extremely convenient, and its adoption expanded rapidly. New kinds of businesses evolved, based on the connectivity of people and the connectivity of software applications all over the world.
Recommended publications
  • Recommended Formats Statement 2019-2020

    Recommended Formats Statement 2019-2020

    Library of Congress Recommended Formats Statement 2019-2020 For online version, see https://www.loc.gov/preservation/resources/rfs/index.html Introduction to the 2019-2020 revision ....................................................................... 2 I. Textual Works and Musical Compositions ............................................................ 4 i. Textual Works – Print .................................................................................................... 4 ii. Textual Works – Digital ................................................................................................ 6 iii. Textual Works – Electronic serials .............................................................................. 8 iv. Digital Musical Compositions (score-based representations) .................................. 11 II. Still Image Works ............................................................................................... 13 i. Photographs – Print .................................................................................................... 13 ii. Photographs – Digital ................................................................................................. 14 iii. Other Graphic Images – Print .................................................................................... 15 iv. Other Graphic Images – Digital ................................................................................. 16 v. Microforms ................................................................................................................
  • The Music Encoding Initiative As a Document-Encoding Framework

    The Music Encoding Initiative As a Document-Encoding Framework

    12th International Society for Music Information Retrieval Conference (ISMIR 2011) THE MUSIC ENCODING INITIATIVE AS A DOCUMENT-ENCODING FRAMEWORK Andrew Hankinson1 Perry Roland2 Ichiro Fujinaga1 1CIRMMT / Schulich School of Music, McGill University 2University of Virginia [email protected], [email protected], [email protected] ABSTRACT duplication of effort that comes with building entire encoding schemes from the ground up. Recent changes in the Music Encoding Initiative (MEI) In this paper we introduce the new tools and techniques have transformed it into an extensible platform from which available in MEI 2011. We start with a look at the current new notation encoding schemes can be produced. This state of music document encoding techniques. Then, we paper introduces MEI as a document-encoding framework, discuss the theory and practice behind the customization and illustrates how it can be extended to encode new types techniques developed by the TEI community and how their of notation, eliminating the need for creating specialized application to MEI allows the development of new and potentially incompatible notation encoding standards. extensions that leverage the existing music document- 1. INTRODUCTION encoding platform developed by the MEI community. We also introduce a new initiative for sharing these The Music Encoding Initiative (MEI)1 is a community- customizations, the MEI Incubator. Following this, we driven effort to define guidelines for encoding musical present a sample customization to illustrate how MEI can documents in a machine-readable structure. The MEI be extended to more accurately capture new and unique closely mirrors work done by text scholars in the Text music notation sources.
  • SOAP Plug-In

    SOAP Plug-In

    User Guide SOAP Plug-in Release 5.0 © 2010 Avaya Inc. All Rights Reserved. Notice While reasonable efforts were made to ensure that the information in this document was complete and accurate at the time of printing, Avaya Inc. can assume no liability for any errors. Changes and corrections to the information in this document may be incorporated in future releases. Documentation disclaimer Avaya Inc. is not responsible for any modifications, additions, or deletions to the original published version of this documentation unless such modifications, additions, or deletions were performed by Avaya. Link disclaimer Avaya Inc. is not responsible for the contents or reliability of any linked Web sites referenced elsewhere within this Documentation, and Avaya does not necessarily endorse the products, services, or information described or offered within them. We cannot guarantee that these links will work all of the time and we have no control over the availability of the linked pages. License USE OR INSTALLATION OF THE PRODUCT INDICATES THE END USER'S ACCEPTANCE OF THE TERMS SET FORTH HEREIN AND THE GENERAL LICENSE TERMS AVAILABLE ON THE AVAYA WEBSITE AT http://support.avaya.com/LicenseInfo/ ("GENERAL LICENSE TERMS"). IF YOU DO NOT WISH TO BE BOUND BY THESE TERMS, YOU MUST RETURN THE PRODUCT(S) TO THE POINT OF PURCHASE WITHIN TEN (10) DAYS OF DELIVERY FOR A REFUND OR CREDIT. Avaya grants End User a license within the scope of the license types described below. The applicable number of licenses and units of capacity for which the license is granted will be one (1), unless a different number of licenses or units of capacity is specified in the Documentation or other materials available to End User.
  • Specification for JSON Abstract Data Notation Version

    Specification for JSON Abstract Data Notation Version

    Standards Track Work Product Specification for JSON Abstract Data Notation (JADN) Version 1.0 Committee Specification 01 17 August 2021 This stage: https://docs.oasis-open.org/openc2/jadn/v1.0/cs01/jadn-v1.0-cs01.md (Authoritative) https://docs.oasis-open.org/openc2/jadn/v1.0/cs01/jadn-v1.0-cs01.html https://docs.oasis-open.org/openc2/jadn/v1.0/cs01/jadn-v1.0-cs01.pdf Previous stage: https://docs.oasis-open.org/openc2/jadn/v1.0/csd02/jadn-v1.0-csd02.md (Authoritative) https://docs.oasis-open.org/openc2/jadn/v1.0/csd02/jadn-v1.0-csd02.html https://docs.oasis-open.org/openc2/jadn/v1.0/csd02/jadn-v1.0-csd02.pdf Latest stage: https://docs.oasis-open.org/openc2/jadn/v1.0/jadn-v1.0.md (Authoritative) https://docs.oasis-open.org/openc2/jadn/v1.0/jadn-v1.0.html https://docs.oasis-open.org/openc2/jadn/v1.0/jadn-v1.0.pdf Technical Committee: OASIS Open Command and Control (OpenC2) TC Chair: Duncan Sparrell ([email protected]), sFractal Consulting LLC Editor: David Kemp ([email protected]), National Security Agency Additional artifacts: This prose specification is one component of a Work Product that also includes: JSON schema for JADN documents: https://docs.oasis-open.org/openc2/jadn/v1.0/cs01/schemas/jadn-v1.0.json JADN schema for JADN documents: https://docs.oasis-open.org/openc2/jadn/v1.0/cs01/schemas/jadn-v1.0.jadn Abstract: JSON Abstract Data Notation (JADN) is a UML-based information modeling language that defines data structure independently of data format.
  • On the Integrity and Trustworthiness of Web Produced Data

    On the Integrity and Trustworthiness of Web Produced Data

    CORE Metadata, citation and similar papers at core.ac.uk Provided by Open Repository of the University of Porto On the Integrity and Trustworthiness of web produced data Luís A. Maia Mestrado Integrado em Engenharia de Redes e Sistemas Informáticos Departamento de Ciência de Computadores 2013 Orientador Professor Doutor Manuel Eduardo Carvalho Duarte Correia, Professor Auxiliar do Departamento de Computadores, Faculdade de Ciências da Universidade do Porto Todas as correções determinadas pelo júri, e só essas, foram efetuadas. O Presidente do Júri, Porto, ______/______/_________ Acknowledgments I would like to express my appreciation for the help of my supervisor in researching and bringing different perspectives and to thank my family, for their support and dedication. 3 Abstract Information Systems have been a key tool for the overall performance improvement of administrative tasks in academic institutions. While most systems intend to deliver a paperless environment to each institution it is recurrent that document integrity and accountability is still relying on traditional methods such as producing physical documents for signing and archiving. While this method delivers a non-efficient work- flow and has an effective monetary cost, it is still the common method to provide a degree of integrity and accountability on the data contained in the databases of the information systems. The evaluation of a document signature is not a straight forward process, it requires the recipient to have a copy of the signers signature for comparison and training beyond the scope of any office employee training, this leads to a serious compromise on the trustability of each document integrity and makes the verification based entirely on the trust of information origin which is not enough to provide non-repudiation to the institutions.
  • XML a New Web Site Architecture

    XML a New Web Site Architecture

    XML A New Web Site Architecture Jim Costello Derek Werthmuller Darshana Apte Center for Technology in Government University at Albany, SUNY 1535 Western Avenue Albany, NY 12203 Phone: (518) 442-3892 Fax: (518) 442-3886 E-mail: [email protected] http://www.ctg.albany.edu September 2002 © 2002 Center for Technology in Government The Center grants permission to reprint this document provided this cover page is included. Table of Contents XML: A New Web Site Architecture .......................................................................................................................... 1 A Better Way? ......................................................................................................................................................... 1 Defining the Problem.............................................................................................................................................. 1 Partial Solutions ...................................................................................................................................................... 2 Addressing the Root Problems .............................................................................................................................. 2 Figure 1. Sample XML file (all code simplified for example) ...................................................................... 4 Figure 2. Sample XSL File (all code simplified for example) ....................................................................... 6 Figure 3. Formatted Page Produced
  • XML Signature/Encryption — the Basis of Web Services Security

    XML Signature/Encryption — the Basis of Web Services Security

    Special Issue on Security for Network Society Falsification Prevention and Protection Technologies and Products XML Signature/Encryption — the Basis of Web Services Security By Koji MIYAUCHI* XML is spreading quickly as a format for electronic documents and messages. As a consequence, ABSTRACT greater importance is being placed on the XML security technology. Against this background research and development efforts into XML security are being energetically pursued. This paper discusses the W3C XML Signature and XML Encryption specifications, which represent the fundamental technology of XML security, as well as other related technologies originally developed by NEC. KEYWORDS XML security, XML signature, XML encryption, Distributed signature, Web services security 1. INTRODUCTION 2. XML SIGNATURE XML is an extendible markup language, the speci- 2.1 Overview fication of which has been established by the W3C XML Signature is an electronic signature technol- (WWW Consortium). It is spreading quickly because ogy that is optimized for XML data. The practical of its flexibility and its platform-independent technol- benefits of this technology include Partial Signature, ogy, which freely allows authors to decide on docu- which allows an electronic signature to be written on ment structures. Various XML-based standard for- specific tags contained in XML data, and Multiple mats have been developed including: ebXML and Signature, which enables multiple electronic signa- RosettaNet, which are standard specifications for e- tures to be written. The use of XML Signature can commerce transactions, TravelXML, which is an EDI solve security problems, including falsification, spoof- (Electronic Data Interchange) standard for travel ing, and repudiation. agencies, and NewsML, which is a standard specifica- tion for new distribution formats.
  • Extensible Markup Language (XML) and Its Role in Supporting the Global Justice XML Data Model

    Extensible Markup Language (XML) and Its Role in Supporting the Global Justice XML Data Model

    Extensible Markup Language (XML) and Its Role in Supporting the Global Justice XML Data Model Extensible Markup Language, or "XML," is a computer programming language designed to transmit both data and the meaning of the data. XML accomplishes this by being a markup language, a mechanism that identifies different structures within a document. Structured information contains both content (such as words, pictures, or video) and an indication of what role content plays, or its meaning. XML identifies different structures by assigning data "tags" to define both the name of a data element and the format of the data within that element. Elements are combined to form objects. An XML specification defines a standard way to add markup language to documents, identifying the embedded structures in a consistent way. By applying a consistent identification structure, data can be shared between different systems, up and down the levels of agencies, across the nation, and around the world, with the ease of using the Internet. In other words, XML lays the technological foundation that supports interoperability. XML also allows structured relationships to be defined. The ability to represent objects and their relationships is key to creating a fully beneficial justice information sharing tool. A simple example can be used to illustrate this point: A "person" object may contain elements like physical descriptors (e.g., eye and hair color, height, weight), biometric data (e.g., DNA, fingerprints), and social descriptors (e.g., marital status, occupation). A "vehicle" object would also contain many elements (such as description, registration, and/or lien-holder). The relationship between these two objects—person and vehicle— presents an interesting challenge that XML can address.
  • Odfweave Manual

    Odfweave Manual

    The OdfWeave Package Max Kuhn max.kuhn@pfizer.com August 7, 2007 1 Introduction The Sweave function (Leisch, 2002) is a powerful component of R. It can be used to combine R code with LATEX so that the output of the code is embedded in the processed document. The capabilities of Sweave were later extended to HTML format in the R2HTML package. A written record of an analysis can be created using Sweave, but additional annotation of the results may be needed such as context–specific interpretation of the results. Sweave can be used to automatically create reports, but it can be difficult for researchers to add their subject–specific insight to pdf or HTML files. The odfWeave package was created so that the functionality of Sweave can used to generate documents that the end–user can easily edit. The markup language used is the Open Document Format (ODF), which is an open, non– proprietary format that encompasses text documents, presentations and spreadsheets. Version 1.0 of the specification was finalized in May of 2005 (OASIS, 2005). One year later, the format was approved for release as an ISO and IEC International Standard. There are several editors/office suites that can produce ODF files. OpenOffice is a free, open source editor that, as of version 2.0, uses ODF as the default format. odfWeave has been tested with OpenOffice to produce text documents. As of the current version, odfWeave processing of presentations and spreadsheets should be considered to be experimental (but should be supported in subsequent versions). OpenOffice can be used to export the document to MS Word, rich text format, HTML, plain text or pdf formats.
  • A Comparative Study on SOAP and Restful Web Services Sirsha Chatterjee1, Mamatha T2

    A Comparative Study on SOAP and Restful Web Services Sirsha Chatterjee1, Mamatha T2

    International Research Journal of Engineering and Technology (IRJET) e-ISSN: 2395-0056 Volume: 07 Issue: 05 | May 2020 www.irjet.net p-ISSN: 2395-0072 A comparative study on SOAP and RESTful web services Sirsha Chatterjee1, Mamatha T2 1Under Graduate Student, Dept. of Computer Science and Engineering, RV College of Engineering, Bengaluru, Karnataka 2Assistant Professor, Dept. of Computer Science and Engineering, RV College of Engineering, Bengaluru, Karnataka ---------------------------------------------------------------------***---------------------------------------------------------------------- Abstract - Modern enterprise applications nowadays need request is sent by the client to the server, where the message to build web-based applications using a wide variety of is processed and appropriate response os sent back to the programming platforms, for different requirements. While client. REST was developed in 2000 by Roy Fielding. [3] backend service applications are developed using Java, .Net, or states that REST services is not only limited to XML but can Node JS, front-end application are developed using ReactJS, also support JSON (JavaScript Object Notation), as well as AngularJS, etc. These heterogeneity in use of types of plain text, unlike SOAP which only supports documents in application platforms require a common communication XML format. service to transfer information and data. Web services provide this service which enables multiple applications to In this paper, the two services are analyzed and compared communicate with each other. Web services perform functions based on their underlying architecture, differences, ranging from simple requests to complicate business advantages and disadvantages. processes. SOAP (Simple Object Access Protocol) and REST (Representational State Transfer) are the most common and 2. SOAP Web Service popular types of web service protocols in use.
  • Darwin Information Typing Architecture (DITA) Version 1.3 Draft 29 May 2015

    Darwin Information Typing Architecture (DITA) Version 1.3 Draft 29 May 2015

    Darwin Information Typing Architecture (DITA) Version 1.3 Draft 29 May 2015 Specification URIs This version: http://docs.oasis-open.org/dita/dita/v1.3/csd01/dita-v1.3-csd01.html (Authoritative version) http://docs.oasis-open.org/dita/dita/v1.3/csd01/dita-v1.3-csd01.pdf http://docs.oasis-open.org/dita/dita/v1.3/csd01/dita-v1.3-csd01-chm.zip http://docs.oasis-open.org/dita/dita/v1.3/csd01/dita-v1.3-csd01-xhtml.zip Previous version: Not applicable Latest version: http://docs.oasis-open.org/dita/dita/v1.3/dita-v1.3-csd01.html (Authoritative version) http://docs.oasis-open.org/dita/dita/v1.3/dita-v1.3-csd01.pdf http://docs.oasis-open.org/dita/dita/v1.3/dita-v1.3-csd01-chm.zip http://docs.oasis-open.org/dita/dita/v1.3/dita-v1.3-csd01-xhtml.zip Technical committee: OASIS Darwin Information Typing Architecture (DITA) TC Chair: Kristen James Eberlein ([email protected]), Eberlein Consulting LLC Editors: Robert D. Anderson ([email protected]), IBM Kristen James Eberlein ([email protected]), Eberlein Consulting LLC Additional artifacts: This prose specification is one component of a work product that also includes: OASIS DITA Version 1.3 RELAX NG: http://docs.oasis-open.org/dita/dita/v1.3/csd01/schemas/ DITA1.3-rng.zip OASIS DITA Version 1.3 DTDs: http://docs.oasis-open.org/dita/v1.3/os/DITA1.3-dtds.zip OASIS DITA Version 1.3 XML Schemas: http://docs.oasis-open.org/dita/v1.3/os/DITA1.3-xsds.zip DITA source that was used to generate this document: http://docs.oasis-open.org/dita/dita/v1.3/ csd01/source/DITA1.3-source.zip Abstract: The Darwin Information Typing Architecture (DITA) 1.3 specification defines both a) a set of document types for authoring and organizing topic-oriented information; and b) a set of mechanisms for combining, extending, and constraining document types.
  • A Framework for Semantic Publishing of Modular Content Objects

    A Framework for Semantic Publishing of Modular Content Objects

    A Framework for Semantic Publishing of Modular Content Objects Catalin David, Deyan Ginev, Michael Kohlhase, Bogdan Matican, Stefan Mirea Computer Science, Jacobs University, Germany; http://kwarc.info/ Abstract. We present the Active Documents approach to semantic pub- lishing (semantically annotated documents associated with a content commons that holds the background ontologies) and the Planetary system (as an active document player). In this paper we explore the interaction of content object reuse and context sensitivity in the presentation process that transforms content modules to active documents. We propose a \separate compilation and dynamic linking" regime that makes semantic publishing of highly struc- tured content representations into active documents tractable and show how this is realized in the Planetary system. 1 Introduction Semantic publication can range from merely equipping published documents with RDFa annotations, expressing metadata or inter-paper links, to frame- works that support the provisioning of user-adapted documents from content representations and instrumenting them with interactions based on the seman- tic information embedded in the content forms. We want to propose an entry to the latter category in this paper. Our framework is based on semantically anno- tated documents together with semantic background ontologies (which we call the content commons). This information can then be used by user-visible, se- mantic services like program (fragment) execution, computation, visualization, navigation, information aggregation and information retrieval (see Figure 5). Finally a document player application can embed these services to make docu- ments executable. We call this framework the Active Documents Paradigm (ADP), since documents can also actively adapt to user preferences and envi- ronment rather than only executing services upon user request.