Cover Pages: XML Daily Newslink: Friday, 20 November 2009

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:
Sun Microsystems, Inc. http://sun.com

Headlines

Public Review for OpenDocument Version 1.2, Part 3: Packages
The OAuth Core 1.0 Protocol
W3C Releases First Public Working Draft of File API
OASIS Public Review Draft: Telecom SOA Use Cases and Issues Version 1.0
Microsoft Proposes OData as de facto Web Data Protocol
XML Namespaces: Default Prefix Declaration
So Much Data, So Little Encryption
How Italy Beat the World to a Smarter Grid
ASTM International Adds Certification Capabilities

Public Review for OpenDocument Version 1.2, Part 3: Packages
Patrick Durusau, Dennis Hamilton, Michael Brauer (eds); OASIS Committee Draft

Members of the OASIS Open Document Format for Office Applications (OpenDocument) Technical Committee have released an approved Committee Draft of Open Document Format for Office Applications (OpenDocument) Version 1.2, Part 3: Packages for public review through January 12, 2010. This TC was chartered to create an open, XML-based file format specification for office applications. OpenDocument Version 1.1 was approved as an OASIS Standard in Februsry 2007.

The OASIS Open Document Format for Office Applications (OpenDocument) specification defines an open, XML-based file format for office applications in three parts. Part 1 defines an XML schema and its semantics for office applications. The format is suitable for office documents, including text documents, spreadsheets, charts and graphical documents like drawings or presentations, but is not restricted to these kinds of documents. Part 2 defines a formula language recommended for use in OpenDocument documents. Part 3 ('Packages') defines a package format for OpenDocument documents.

"As XML has no native support for binary objects such as images and other media types, and because uncompressed XML files can become very large, OpenDocument uses a package file to store the XML content of a document as separate parts together with associated binary data as file entries in a single package file. These file entries may be compressed to further reduce the storage taken by the package. This package is a ZIP file... A document within a package may consist of a set of files creating a unit, for instance the set of files specified by OpenDocument part 1. These files may be located in the root of the package, or within a directory. If they are contained in the root of the package, they are called document. If they are located within a directory, the document they constitute is called a sub document. A package may contain multiple sub documents, but only a single document may be contained in the root of the package...

OpenDocument packages may be encrypted by encrypting the files within the package. Files within a package may have a digital signature applied. Metadata for documents contained in an OpenDocument package may be expressed using the model of the W3C Resource Description Framework. Metadata manifest files enumerate metadata files and their relationships to other files in that document or sub document as defined by this specification. The format of the manifest file is defined by the OpenDocument manifest Relax-NG schema. The relationships are expressed in the metadata manifest files using the W3C Recommendation 'RDF/XML Syntax Specification (Revised)' and the OWL Ontology (OpenDocument Package Metadata Manifest Ontology that is defined in appendix B... The DSIG Schema, Manifest Schema, OWL Ontology, and OpenDocument Package Metadata Manifest Ontology XML namespace document are available as separate files."

The OAuth Core 1.0 Protocol
Eran Hammer-Lahav (ed), IETF Internet Draft

Members of the IETF Open Authentication Protocol (OAuth) Working Group have published a revised Internet Draft for The OAuth Core 1.0 Protocol specification with an invitation for public review. OAuth "provides a method for clients to access server resources on behalf of another party (such as a different client or an end user). It also provides a redirection-based user-agent process for end users to authorize access to another party by using their credentials (typically, a username and password pair) and providing the client with a different set of delegation-specific credentials.

For example, a web user (resource owner) can grant a printing service (client) access to its private photos stored at a photo sharing service (server), without sharing its credentials with the printing service. Instead, the user authenticates directly with the photo sharing service and issues the printing service delegation-specific credentials. OAuth introduces a third role to the traditional client-server authentication model: the resource owner. In the OAuth model, the client requests access to resources controlled by the resource owner and hosted by the server. In addition, OAuth allows the server to verify not only the resource owner's credentials, but also those of the client making the request.

In order for the client to access resources, it first has to obtain permission from the resource owner. This permission is expressed in the form of a token and matching shared-secret. The purpose of the token is to substitute the need for the resource owner to share its credentials (usually a username and password pair) with the client. Unlike resource owner credentials, tokens can be issued with a restricted scope and limited lifetime.

This specification consists of two parts. The first part defines a redirection-based user-agent process for end users to authorize client access to their resources, by authenticating directly with the server and provisioning tokens to the client for use with the authentication method. The second part defines a method for making authenticated HTTP requests using two sets of credentials, one identifying the client making the request, and a second identifying the resource owner on whose behalf the request is being made..."

Updated to version -07 on 2009-11-23: corrected typos; shanged examples to use HTTPS in authorization step; clarified the use of 'oauth_' tokens in the three static endpoint URIs; edited abstract and introduction. Status: IESG Evaluation ("... now being formally reviewed by the entire IESG. Documents are discussed in email or during a bi-weekly IESG telechat. In this phase, each Area Director reviews the document and airs any issues they may have. Unresolvable issues are documented as "discuss" comments that can be forwarded to the authors/Working Group...")

W3C Releases First Public Working Draft of File API
Arun Ranganathan (ed), W3C Technical Report

A First Public Working Draft has been published by W3C for the File API specification. The document was produced by members of the W3C Web Applications Working Group, part of the Rich Web Clients Activity, in the W3C Interaction Domain.

File API defines: "(1) A FileList sequence, which represents an array of individually selected files from the underlying system. (2) A Blob interface, which represents raw binary data, and allows access to ranges of bytes within the Blob object. (3) A File interface, which includes 'read-only' informational attributes about a file such as its name, its mediatype, and a URL to access its data. (4) A FileReader interface, which provides methods to read a File, and an event model to obtain the results of these reads. (5) A FileError interface and a FileException exception which define error conditions used by this specification...

"Web applications should have the ability to manipulate as wide as possible a range of user input, including files that a user may wish to upload to a remote server or manipulate inside a rich web application. This specification defines the basic representations for files, lists of files, errors raised by access to files, and programmatic ways to read files. The interfaces and API defined in this specification can be used with other interfaces and APIs exposed to the web platform...

File reads should happen asynchronously on the main thread, with an optional synchronous API used within threaded web applications. An asynchronous API for reading files prevents blocking and UI 'freezing' on a user agent's main thread. This specification defines an asynchronous API based on an event model to read and access a file's data. Moreover, this specification defines separate interfaces for files and the objects used to read a file's data. While a File object provides a reference to a single file that a user has selected from a file picker (typically spawned by the HTML input element), a FileReader object provides asynchronous read methods to access that file's data through event handler attributes and the firing of events. The use of events and event handlers allows separate code blocks the ability to monitor the progress of the read (which is useful for remote drives that appear to be local, but behave slower than local drives), error conditions that may arise, and successful reading of a file..."

OASIS Public Review Draft: Telecom SOA Use Cases and Issues Version 1.0
Enrico Ronco (ed), OASIS Committee Draft

Members of the OASIS SOA for Telecom (SOA-Tel) Technical Committee have released an approved Committee Draft of Telecom SOA Use Cases and Issues Version 1.0 for public review through January 19, 2010.

"Service-Oriented Architecture, SOA, is a design approach that divides everyday business applications into individual processes and functions, otherwise termed 'service components'. These service components can then be deployed and integrated among any supporting applications and run on any computing platform. SOA enables a business to drive its application architecture by aligning the business processes with the information technology infrastructure. In effect the composite application becomes a collection of services communicating over a message bus via standard interfaces and allowing each component to be incorporated into the business process flow creating loosely coupled reusable component architecture...

This document is the first deliverable produced within the SOA-TEL TC and has the objective of collecting potential technical issues and gaps of SOA standards (specified by OASIS and other SDOs) utilized within the context of Telecoms. All perceived technical issues on SOA standards contained in this document are structured with a description of the context, a use case, and a rationalization of the possible gap within the standard. Amongst future deliverables of the SOA-TEL TC there is a Requirements specification, which will aim to extend the current core SOA enabling stack (Web Services and/or REST, etc.) in support of Telecom needs on the basis of the issues identified within the present document.

This OASIS TC was chartered to identify the standards consistent with Web 2.0 and SOA principles that may be more useful to Telecom providers/ operators as a means of leveraging Telecom Services in business applications, and to assess whether there are inherent limitations in such use. The work generates requirements that help to address any identified limitations or gaps in current existing standards that the TC identifies as possible candidates in support of Telecom operators in terms of testability, scalability, Service Level Agreements (SLA), reliability, support for session interactions, event based interactions, service ontologies, service failure modes, and the marrying of Web 2.0 and SOA technologies..."

See also: the OASIS announcement

Microsoft Proposes OData as de facto Web Data Protocol
Abel Avram, InfoQueue

"Microsoft proposes OData as the web data protocol while Google uses GData. Microsoft invites Google to join forces with them in adopting OData. Will they do it? The Open Data Protocol (OData) is a protocol for querying and updating data on the web, being a set of extensions to the AtomPub protocol. AtomPub is an HTTP-based protocol used for the same purpose, to create and update web resources, working in conjunction with the Atom Syndication Format, an XML-based language used for web feeds. OData was previously known as the Astoria Protocol, ADO.NET Data Services Protocol or as a set of conventions/extensions to AtomPub...

Google has a very similar protocol called Google Data Protocol (GData), having the same purpose of extending AtomPub, and it has client libraries for Java, JavaScript, .NET, PHP, and Python. Besides, GData extends RSS 2.0 too. Already as version 2.0, GData is used internally by Google across many services accessing data..."

According to the Open Data Protocol (OData) web site: "The Open Data Protocol (OData) is a web protocol for querying and updating data. OData applies web technologies such as HTTP, Atom Publishing Protocol (AtomPub) and JSON to provide access to information from a variety of applications, services, and stores. This protocol emerged organically based on the experiences implementing AtomPub clients and servers in a variety of products over the past several years. OData is being used to expose and access information from a variety of sources, including but not limited to relational databases, file systems, content management systems, and traditional web sites. Microsoft has released OData under the Open Specification Promise (OSP) to allow anyone to freely interoperate with OData implementations. We intend on working with the community to move the features of OData into future version of AtomPub or other appropriate standards.

OData is consistent with the way the web works. OData makes a deep commitment to URIs as a means to identify resources (just like the web). OData commits to an HTTP-centric protocol with a uniform interface for interacting with those resources (again, just like the web). OData builds on the conventions over HTTP popularized by AtomPub, which have simplified the process of sharing data, content and information across independently developed systems. OData defines additional conventions that implementations may optionally implement to support basic query and schema information to be exchanged. To simplify integration with HTML and JavaScript clients, OData defines an optional JSON representation of the protocol that complements the XML-based AtomPub format..."

XML Namespaces: Default Prefix Declaration
Henry S. Thompson, W3C Blog

"Criticism of XML namespaces as an appropriate mechanism for enabling distributed extensibility for the Web typically targets two issues: (1) Syntactic complexity and (2) API complexity. Of these, the first is arguably the more significant, because the number of authors exceeds the number of developers by a large margin. Accordingly, this proposal attempts to address the first problem, by providing a defaulting mechanism for namespace prefix bindings which covers the 99% case...

XML namespaces provide two essentially distinct mechanisms for 'owning' names, that is, preventing what would otherwise be a name collision by associating names in some way with some additional distinguishing characteristic: (a) by prefixing the name, and binding the prefix to a particular URI; (b) by declaring that within a particular subtree, unprefixed names are associated with a particular URI. In XML namespaces as they stand today, the association with a URI is done via a namespace declaration which takes the form of an attribute, and whose impact is scoped to the subtree rooted at the owner element of that attribute. Liam Quin has proposed an additional, out-of-band and defaultable, approach to the association for unprefixed names, using patterns to identify the subtrees where particular URIs apply. I've borrowed some of his ideas about how to connect documents to prefix binding definitions. The approach presented here is similar-but-different, in that its primary goal is to enable out-of-band and defaultable associations of namespaces to names with prefixes, with whole-document scope...

This proposal uses a binding: define a trivial XML language which provides a means to associate prefixes with namespace names (URIs). Invoking from HTML: define a link relation dpd for use in the (X)HTML header. Invoking from XML: define a processing instruction 'xml-dpd' and/or an attribute 'xml:dpd' [default prefix declaration] for use at the top of XML documents. Defaulting by Media Type: implement a registry which maps from media types to a published dpd file. Semantics: define a precedence, which operates on a per-prefix basis, namely: 'xmlns: - explicit invocation - application built-in default - media-type-based default' and a semantics in terms of namespace information items or appropriate data-model equivalent on the document element..."

See also: Namespaces in XML

So Much Data, So Little Encryption
Michael A. Davis, InformationWeek

"We surveyed almost 500 business technology professionals and found little end-to-end encryption use—only what auditors demand... If you go solely by top-level stats on encryption use, you'll come away feeling pretty secure: 86% of the the 499 business technology professionals responding to our InformationWeek Analytics State of Encryption Survey employ encryption of some type. But that finding doesn't begin to tell the real story. Only 14% of respondents say encryption is pervasive in their organizations. Database table-level encryption is in use by just 26%, while just 38% encrypt data on mobile devices. And 31% (more than any other response) characterize the extent of their use as just enough to meet regulatory requirements.

Network Computing examined the state of enterprise encryption in 2007 and found adoption to be a gradual process, often starting with backup tapes and spreading from there. A piecemeal approach was the norm then, and we're still moving in fits and starts, despite the momentum generated by compliance frameworks such as PCI, which requires encryption of credit card data in transit..."

The Interoperability Factor: "Part of the problem is that standards efforts have yielded exactly zero breakthroughs where we need them most—in interoperability, which would make encryption management easier and less expensive... A few desperate souls wished for more regulation, or even a breach that would require notification of customers, to use as leverage for gaining funding and management buy-in.."

How Italy Beat the World to a Smarter Grid
Mark Scott, BusinessWeek

"An aggressive rollout of intelligent electrical meters is saving Italy's Enel $750 million per year, and cutting customers' bills... After several false starts, 2010 finally could be the year when smar meters go global. The technology, which lets energy companies and consumers more closely monitor their electricity consumption, has many champions. The U.S. government has earmarked $4.5 billion from the stimulus package to subsidize the rollout of smart meters nationwide. European Union politicians are pushing hard to connect 80% of the region's homes and businesses to smart meters by 2020. Even emerging giants like India and China aim to install the technology in new buildings...

Some 85% of Italian homes are now outfitted with smart meters—the highest percentage in the world and more such devices than exist in the whole of the U.S. Utilities worldwide, such as San Francisco's PG&E (PCG) and Florida's FPL Group (FPL), are eager to learn how Enel pulled off its smart meter revolution.

ASTM International Adds Certification Capabilities
Staff, American Society for Testing and Materials Announcement

"The ASTM Board of Directors in October, 2009 has authorized the ASTM management to move forward and develop the capability to offer ASTM Certification Programs for products (material, products, systems and services) and personnel... ASTM International is one of the largest voluntary standards development organizations in the world-a trusted source for technical standards for materials, products, systems, and services. Known for their high technical quality and market relevancy, ASTM International standards have an important role in the information infrastructure that guides design, manufacturing and trade in the global economy...

The ASTM Board decision on certification was the result of having received several inquires, particularly related to new standard development activities, questioning whether ASTM could provide certification to industries that desire an independent third party demonstration of compliance to standards and from industries facing regulatory pressures to prove compliance to standards. The offering of certification programs as a part of ASTM's portfolio of services is similar to our successful proficiency testing and training programs..."


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

Headlines

Sponsors