DOCSLIB.ORG

Active Documents and Their Applicability in Distributed Environments

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Active Documents and Their Applicability in Distributed Environments Active Documents and their Applicability in Distributed Environments Martin Fredriksson University College of Karlskrona/Ronneby Department of Computer Science and Business Administration S-372 38 Ronneby email: [email protected] $EVWUDFW$FWLYH'RFXPHQWVLVDWHFKQLTXHIRUDXWRPDWLQJWKHKDQGOLQJDQGFRQWURORIGRFXPHQWVE\ PDNLQJWKHPDFRPELQDWLRQRIVHUYLFHSURYLGHUV PRELOHDJHQWV DQGUHVRXUFHV FRPSRXQGGRFX PHQWV LQWKHIRUPRIDXWRQRPRXVDJHQWV7KHPDLQIRFXVRIWKLVVROXWLRQLVWRSURYLGHDQHQFDSVXOD WLRQ RI GRFXPHQWV LQFOXGLQJ WKHLU GDWD VWUXFWXUHV DQG UHODWHG IXQFWLRQDOLW\ EXW DOVR WR HQDEOH GRFXPHQWV WR UHIOHFW XSRQ WKHPVHOYHV LQ UHVSHFW RI WKHLU FRPSXWDWLRQDO HQYLURQPHQW DQG WDNH DFWLRQVDFFRUGLQJO\ .H\ZRUGV$FWLYH'RFXPHQWV6HUYLFH2ULHQWHG$UFKLWHFWXUHV&RPSRXQG'RFXPHQWVDQG0RELOH 6RIWZDUH$JHQWV &RQWHQWV 1 Introduction 1 1.1 Problem Description 1 The Evolution of Digital Documents 1 Limited Architectures 3 Limited Component Property Support 3 Fundamental Domain Issues 5 1.2 Approach to Problem Solution 6 Software Agents 6 The Thesis 7 1.3 Outline of the Thesis 7 1.4 Acknowledgements 8 2 Supporting Concepts and Technologies 9 2.1 Abstraction and Representation 9 Data Abstraction 10 Data Representation 11 2.2 Components, Documents, and Compound Documents 12 Components 12 Documents 13 Compound Documents 13 2.3 Software Agents 15 Active Objects 16 Mobile Objects 16 Conceptual Adherence 17 Communication Language 17 Behavior and Knowledge 18 Service-Oriented Architectures 18 2.4 Discussion 19 Implications of Abstractions 19 Requirements Implied by the Abstraction 20 3 Active Documents 22 3.1 Service-Oriented Architectures 22 Facilitators 22 Handlers 23 Services 24 3.2 Software Agents and Related Issues 25 Footprint 25 Mobility 25 Activation and Scheduling 26 Communication and Cooperation 26 3.3 Active Documents 27 Type Hierarchy 27 Entity Associations 28 3.4 Active Document Handling 29 Creating an Active Document 29 Storing an Active Document 29 Accessing an Active Document 29 &RQWHQWV LL 3.5 Discussion 30 4 Delving Into Active Documents 31 4.1 Business Workflow Processes 31 Case Study 31 4.2 A Different Point of View 33 Decision Styles 34 Markup Languages and Context 34 Combining Information Structure, Context, and Active Documents 35 4.3 Personal Assistants 37 Control Agents 37 4.4 Discussion 37 5 Summary and Conclusions 39 5.1 The Problem 39 5.2 Active Documents and Applicability in Distributed Environments 40 Conformance to the Problem Domain 40 Implications of the Active Document Approach 40 Applicability in Distributed Environments 41 5.3 Future Work 41 Appendix A - Architecture Design 42 References 43 ,QWURGXFWLRQ For centuries, documents have served as a way to record and share events of the past and present. Therefore, we can say that documents are a mechanism of knowledge sharing. In general, a docu- ment seems mostly concerned with the layout of text and/or images to be printed on paper of appro- priate quality. This view of a document is complemented with the notion of a digital document, and is more focused on the way information is most appropriately structured and handled for updating and access. The main difference between these two concepts is the new ways of information interac- tion and knowledge sharing that digital documents offer us. Thus, an area of applicability for digital documents is business workflow processes [4][6]. Nowadays documents have become vitally important components in workflow processes. Every organization with some self respect is trying to get in control of how digital information (mostly doc- uments of different types) in the organization is passed from one person to another and interacted with. One of the main concerns, when it comes to workflow processes, is therefore how we repre- sent, interact, and share information participating in the processes. In the general case, we tend to conceptualize information as computerized versions of physical documents. However, such an approach has one major drawback: workflow processes by nature involve activity, and computerized documents of today do not. In order to achieve the necessary activity in the workflow processes we have to make use of applications as a complement to the inactive data structures. The problem with this approach is threefold: it is difficult to combine the services offered by different applications with each other, most applications make use of non-compatible native storage formats, and it is difficult to model processes and activity using a static set of functionality offered by the applications. In combi- nation with each other, these three problems put us in a somewhat awkward position: we cannot cre- ate and/or control our workflow processes in a satisfying manner, due to the basic architecture we have chosen to model the relationship between activity (functionality) and information (document data). The questions are: (1) what are the fundamental issues of interest for both the document domain and business workflow area of research? (2) can we find an architecture/model that addresses these fun- damental issues in a more appropriate manner than current ones? 3UREOHP'HVFULSWLRQ In the following section a number of issues will be discussed, namely, an identification of where we are standing today concerning digital documents (digital document evolution), and the identification of problem issues related to digital documents with focus on business workflow processes and the modeling of activity. 7KH(YROXWLRQRI'LJLWDO'RFXPHQWVIn order to show what a digital document today really is, a brief outline of document evolution and historical background will be given below: • 3KDVH6XSSRUWIRU0XOWLSOH'RFXPHQW'DWD7\SHV- The main difference between the docu- ments used in the early days of computerized business and the ones we use today is that they only contained one type of data, and this data was stored according to some native application’s spe- cific storage format. Furthermore, the document applications could not handle any other data structures than their own native storage formats. Therefore, in order to create a document of mul- tiple types of data, the user had to generate output from a set of applications, and then integrate these outputs by hand. In other words, it was a so called cut and paste approach. Then, if a docu- 3UREOHP'HVFULSWLRQ ment contained any errors, the user would have to start the process all over again. Obviously, the approach of creating documents by hand was very cumbersome. However, a new approach in document handling was developed, the tool-centric integration approach. The main reason for developers to take the next step in document evolution (tool-centric integration), was a direct result of computer environments where document applications were running and documents were stored. Meaning, computer systems were developed that could support a network of output from multiple applications. This enabled the users to create documents containing multiple data struc- tures of different media types. However, the applications were only able to change specific parts of a document that were represented in the native format of that application. All other structures contained in the applications’ documents still had to be changed in their corresponding applica- tion, and reimported. As applications started to enable users to import different types of data structures, the applications became more complex. • 3KDVH6XSSRUWIRU$SSOLFDWLRQ,QGHSHQGHQW3DUW+DQGOHUV- There have been attempts to solve the problem of complexity versus functionality, by extracting the interaction with document parts (data structures of different types) from the applications, and putting functionality into separate objects that all applications can share. This approach is often denoted as a so called compound document approach1. By applying such an approach the applications can support documents con- taining a multitude of data-types, without increasing the complexity of the specific application, and still offer the users all the functionality they might want. The compound document approach is characterized by the extensive use of specialized components2, encapsulating the various data structures, that form the structure of a compound document. • 3KDVH6XSSRUWIRU6LWXDWHG$FWLRQV- Since documents nowadays are becoming more and more important as means for knowledge sharing and information interaction it is important that the documents support situated actions. The reason to this is the fact that it enables the documents to perform different actions depending on the current situation at hand, no matter if the action is related to visualization or something completely different. This requirement is for example of major interest in compound document systems, focusing on visualization aspects of document data. In such systems each document part is responsible for its own visualization, instead of rely- ing on external applications. Depending on part type and current situation, different visualizations can be applied by a document part. This feature is also of utmost importance in workflow pro- cesses, since it would enable us to get in control of the information flow processes and possibly also to automate parts of them. It is obvious that a digital document today no longer conforms to the definition and properties of a physical document. During their evolution, digital documents has adopted new technological advancements, but maybe most notably, new requirements have been imposed on the documents by the systems that handle them and by their users and new areas
Load more

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]
  • 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.
    [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]