Cover Pages: XML Daily Newslink: Wednesday, 07 April 2010

A Cover Pages Publication http://xml.coverpages.org/
Provided by OASIS and Sponsor Members
Edited by Robin Cover

This issue of XML Daily Newslink is sponsored by:
Oracle Corporation http://www.oracle.com

Headlines

W3C Invites Public Comment on First Working Draft of 'File API: Writer'
OASIS Public Review: Extensible Resource Descriptor (XRD) Version 1.0
Link Relation Types for Simple Version Navigation between Web Resources
Create Client-Side Diagrammatic Interaction in Web Applications with SVG
NIST Roadmap for Digital Preservation Interoperability Framework

W3C Invites Public Comment on First Working Draft of 'File API: Writer'
Eric Uhrhane (ed), W3C Technical Report

Members of the W3C Device APIs and Policy Working Group have published the First Public Working Draft for the specification File API: Writer. This document is on the W3C Recommendation track, and represents an early consensus of the group on the scope and features of the proposed 'File API: Writer'. Issues and editors notes in the document highlight some of the points on which the group is still working and would particularly like to get public feedback. The mission of the Device APIs and Policy Working Group is to create client-side APIs that enable the development of Web Applications and Web Widgets that interact with devices services such as Calendar, Contacts, Camera, etc.

"Summary: Web applications are currently fairly limited in how they can write to files. One can present a link for download, but creating and writing files of arbitrary type, or modifying downloaded files on their way to the disk, is difficult or impossible. This specification define s an API through which user agents can permit applications to write generated or downloaded files. It defines an API for writing to files from web applications, and is designed to be used in conjunction with, and depends on definitions in, other APIs and elements on the web platform...

The File API specification published as a W3C Working Draft in November 2009 defined interfaces for reading files, manipulation of Blobs of data, and errors raised by file accesses. This 'File API: Writer' specification extends that work with a way to construct Blobs and with synchronous and asynchronous file-writing interfaces. As with reading, writing files on the main thread should happen asynchronously to avoid blocking UI actions. Long-running writes provide status information through delivery of progress events.

The API includes: (1) A BlobBuilder interface, which enables one to build a Blob from a String; (2) A FileWriter interface, which provides methods to write a Blob to a file, and an event model to obtain the results of those writes; (3) A FileWriterSync interface, which provides methods to write a Blob to a file synchronously from the Worker context..."

OASIS Public Review: Extensible Resource Descriptor (XRD) Version 1.0
Eran Hammer-Lahav and Will Norris (eds), OASIS Public Review Draft

Members of the OASIS Extensible Resource Identifier (XRI) Technical Committee have approved Extensible Resource Descriptor (XRD) Version 1.0 as a Committee Draft and approved the specification for public review through May 05, 2010. This specification was previously submitted for a 60-day public review on 9-November-2010. This 30-day review is limited in scope to changes made from the previous review in Working Drafts #10-15.

"Extensible Resource Descriptor (XRD) is a simple generic format for describing and discovering resources. Resource descriptor documents provide machine-readable information about resources (resource metadata) for the purpose of promoting interoperability. They also assist in interacting with unknown resources that support known interfaces.

For example, a web page about an upcoming meeting can provide in its descriptor document the location of the meeting organizer's free/busy information to potentially negotiate a different time. The descriptor for a social network profile page can identify the location of the user's address book as well as accounts on other sites. A web service implementing an API protocol can advertise which of the protocol's optional components are supported...

An XRD document may describe the properties of the resource itself, as well as the relations the resource has with other resources. XRD builds directly on the typed link relations framework defined by the IETF Standards Track specification on 'Web Linking', and used by HTML 4.01, Atom 1.0, and other protocols. An XRD document must: (a) be a well-formed XML document as defined by XML 1.0 with a root element of [name] 'XRD' (b) validate against the normative XRD schema, and (c) adhere to the additional syntactic constraints as defined in document Section 1.5... The XRD schema defines only the elements necessary to support the most common use cases, with the explicit intention that applications will extend XRD as defined in Section 3 ('XRD Extensibility') to include other metadata about the resources and links they describe..."

See also: the OASIS XRI TC web site

Link Relation Types for Simple Version Navigation between Web Resources
Al Brown, Geoffrey Clemm, Julian F. Reschke; IETF Informational RFC

A posting from The RFC Editor Team announces the availability of IETF I-D Link Relation Types for Simple Version Navigation between Web Resources as an Informational Request for Comments (RFC) in the RFC libraries (ISSN 2070-1721). The RFC is based upon the version -07 IETF Internet Draft in which the specification title was changed from (version -06) Link Relations for Simple Version Navigation.

This IETF specification defines a set ot link relation types that may be used on Web resources that exist in a system that supports versioning to navigate among the different resources available, such as past versions and working copies. These link relations are used in the AtomPub (RFC 5023: 'The Atom Publishing Protocol') bindings of the 'Content Management Interoperability Services' (CMIS) specification.

Overview: As to terms: "When a resource is put under version control, it becomes a 'versioned resource'. Many servers protect versioned resources from modifications by considering them 'checked in', and by requiring a 'checkout' operation before modification, and a 'checkin' operation to get back to the 'checked-in' state. Other servers allow modification, in which case the checkout/checkin operation may happen implicitly... A 'version history' resource is a resource that contains all the versions of a particular versioned resource... When a versioned resource is checked out and then subsequently checked in, the version that was checked out becomes a 'predecessor' of the version created by the checkin... A 'working copy' is a resource at a server-defined URL that can be used to create a new version of a versioned resource... A 'checkout' is an operation on a versioned resource that creates a working copy, or changes the versioned resource to be a working copy as well... A 'checkin' is an operation on a working copy that creates a new version of its corresponding versioned resource..."

The following link relations are defined in this specification: (1) 'version-history' - when included on a versioned resource, this link points to a resource containing the version history for this resource; (2) 'latest-version' - when included on a versioned resource, this link points to a resource containing the latest (e.g., current) version; the latest version is defined by the system, and for linear versioning systems, this is probably the latest version by timestamp; (3) 'working-copy' - when included on a versioned resource, this link points to a working copy for this resource; some systems may allow more than one of these link relations; (4) 'working-copy-of' - when included on a working copy, this link points to the versioned resource from which this working copy was obtained; (5) 'predecessor-version' - when included on a versioned resource, this link points to a resource containing the predecessor version in the version history; some systems may allow more than one of these link relations in the case of multiple branches merging; (6) 'successor-version' - when included on a versioned resource, this link points to a resource containing the successor version in the version history..."

Create Client-Side Diagrammatic Interaction in Web Applications with SVG
Cameron Laird, IBM developerWorks

"The maturity of SVG allows for a little-known style of use and development of currently undocumented visual elements. In a time when data-as-a-service is blossoming, it makes a lot of sense to script SVG instances from an enclosing Web application. A specific example of a dynamic choropleth illustrates how easy this technique can be... This article will interest both Web developers and their managers. While the coding is simple enough to be thoroughly understood, it models a GUI effect that goes beyond traditional form-based Web application. The effect: (1) Depends only on public standards; (2) Performs at least as well as proprietary alternatives; (3) Opens up new models of teamwork and collaboration; (4) Represents an implementation technique that has apparently never before been documented explicitly...

The article has three aims: to demonstrate the operation of a specific standards-compliant Web-based GUI effect for a user perspective; to explain the model as an example of deep partnership between Web and SVG technologies from a developer's perspective; to illustrate how HTML5 promotes new divisions of labor in development of complex Web applications, as team leads will want to know. It is written for those who can effectively read the HTML and JavaScript typical of Web pages, but not necessarily write these languages fluently. No prior experience with SVG is necessary. Familiarity with XML is required. While there is no dependence in the presentation on a particular operating system, exposure to a range of browsers is expected...

Until recently, though, dynamic graphical interaction was largely the domain of proprietary or desktop applications. As this article shows, SVG now makes a good foundation for advanced standards-based effects with Web applications. SVG and, more generally, the collection of capabilities abbreviated as HTML5, open Web application development to dramatic new frontiers... As data as a service takes off, SVG will enable a wide range of visualizations which will be conveniently de-coupled from particular content. In the early days of the Web, the only facilities which provided the possibility of interaction of the sort this article illustrates were image maps and proprietary plugins. The former were notoriously tedious to write and even harder to maintain. SVG, in contrast, acts as a higher-level language for development of a wide range of graphical effects.

Bio Note: "For long-time developer Cameron Laird, 'graphics' has, on different occasions, meant everything from images of brains scans and aircraft cockpit displays to pipeline control boards and commodity market charts. He's an enthusiastic Invited Expert to the W3C SVG Interest Group precisely because SVG promises to relieve so many problems common to these diverse domains. Cameron also is a prolific author of articles for developerWorks and other professional publications, as well as the Smart Development blog. Cameron consults as vice-president of Phaseit, Inc., which he co-founded..."

NIST Roadmap for Digital Preservation Interoperability Framework
Staff, NIST Announcement

NIST is sponsoring a two-part series on roadmap development for Digital Preservation Interoperability Framework. The goals are to establish a U.S. national roadmap on long-term digital preservation standardization by identifying requirements, technologies, and best practices. This roadmap will then feed into the Study Group on Digital Content Management and Protection (SGDCMP) of the Joint Technical Committee (JTC 1) of the International Organization for Standardization and International Electrotechnical Commission (ISO/IEC) in order for SGDCMP to standardize digital preservation interoperability framework for effectively and reliably access the preserved digital contents between interoperable digital preservation repositories.

Digital data and content are continuing be the core foundation of the U.S. knowledge heritage. Examples range from digitize historical maps and manuscripts, high throughput sensor data from unmanned aerial vehicle and advanced medical imaging devices, national records and financial transactions, modeling and simulation of reconstruction of earthquake and building collapse, physical health records and medical history, personal collection of photos and videos from consumer electronics, to social networking from blogs and emails. The ability to effectively manage and protect these national assets is increasingly crucial as digital technology continues to produce vast amounts of valuable and irreplaceable knowledge and information...

A recent study by the International Data Corporation has shown that the amount of digital data being produced had risen to 281 exabytes (EB, 1018) in 2007 and estimates the total amount of digital information will grow at a rate of 58% per year, reaching 1610 EB by 2011! Each EB is equivalent to 50,000 times the entire U.S. Library of Congress' printed collection. Reliable access to the lifecycle of archival knowledge and information impact all facets of mankind: national heritage, homeland security, health and safety, financial institutes, manufacturing, and education, just to name a few...

The INCITS/DCMP project organizers have invited digital preservation experts to submit a questionnaire-based paper in this roadmap effort, especially those experts that are involved in: (1) Organizations -- government, public/private institutes, etc.—handling the preservation operations, strategies, and requirements; (2) Technology developments -- academia, commercial companies, R&D labs, etc.—providing preservation best practices and solutions; (3)Standards bodies—ISO/IEC, consortiums, industry associations, government initiatives, etc.—establishing preservation best practices in the areas of metadata (content description), file format (content container), packaging (content deliverer), management (inside/outside file format), protection (inside/outside file format or packaging)..."


SEARCH \| ABOUT \| INDEX \| NEWS \| CORE STANDARDS \| TECHNOLOGY REPORTS \| EVENTS \| LIBRARY

Headlines

Sponsors