Cover Pages: XML Daily Newslink: Wednesday, 29 September 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:
Microsoft Corporation http://www.microsoft.com

Headlines

SOA Repository Artifact Model and Protocol (S-RAMP) Technical Committee
Web on TV: Towards Smarter Integration of Web and Broadcasting
A Location Dereferencing Protocol Using HELD
Revised Working Draft for Widget Updates Specification
Representing Predictive Solutions in PMML

SOA Repository Artifact Model and Protocol (S-RAMP) Technical Committee
Staff, OASIS Announcement

OASIS members Active Endpoints, Hewlett-Packard, IBM, Red Hat, SOA Software, Software AG, TIBCO Software, WebLayers, and WSO2 have submitted a charter proposal for a SOA Repository Artifact Model and Protocol (S-RAMP) Technical Committee. As proposed, the TC would "accept as input Version 1.0 of the S-RAMP specification published by HP, IBM, Software AG, and TIBCO. The S-RAMP specification is divided in to two logical modules: The Foundation and The Atom Binding. The TC will also accept as input a list of issues and recommended changes from the authoring companies.

The scope of the TC's first set of deliverables includes further refinement of the Input Documents, addressing issues raised by authoring companies, incorporating appropriate additional contributions to the TC, and addressing issues raised in the TC itself. The output of the TC is the standardization of these documents extension points, conformance targets, capabilities and concepts therein.

Capabilities for S-RAMP presented in the charter proposal: (1) Create, Read, Update and Delete operations for the concepts defined below in the concepts section. (2) Query of repository information based upon the repository's content and metadata, including, but not limited to XPath. (3) Rendering of the Artifact Type models in a form appropriate to a binding. (4) Declaring the S-RAMP specific extensions to the Atom Publishing Protocol. This encompasses, but is not limited to details documented in input document describing the Atom binding. Specifically, details about the addition, mutation, query, and deletion of artifacts are defined here. (5) The S-RAMP Atom Binding will facilitate both a coarse-grained and fine-grained interaction with the artifact type models described below. The coarse-grained interaction describes how to perform CRUD operations on an S-RAMP artifact via HTTP methods, how to create multiple artifacts via HTTP Batch, and how to retrieve artifacts via HTTP GET. The fine-grained interaction provides a hierarchical representation for a given class of metadata (relationships, properties, or classifications), and provides CRUD operations for these sections using HTTP. (6) Query of S-RAMP Artifacts and associated metadata via ATOM defined in the S-RAMP Atom Binding. This includes use of inline queries via HTTP GET/POST as well as use of stored queries.

The current S-RAMP Foundation document: "In today's environment, vendors offer tools to facilitate various activities across the life cycle of a SOA artifact, such as design, assembly, quality assurance, deployment and runtime operation of SOA based applications and business processes. The SOA repository provides the foundation for all these activities...S-RAMP codifies how SOA information models are represented by artifacts (including their associated metadata) in a SOA repository. This specification also defines bindings to support interaction with the SOA repository, including create, read, update, delete, query, and subscription for notifications. It defines the Artifact Type Model and provides various bindings which define the syntax needed to support interaction with a SOA repository. This approach to providing flexible access to SOA artifacts will facilitate interoperability and provide customers with more choices of tools that can be used to interoperate with any S-RAMP compliant SOA repository implementation..."

See also: the S-RAMP web site

Web on TV: Towards Smarter Integration of Web and Broadcasting
Staff, W3C Announcement

"The explosion of the mobile device market demonstrates how consumers have come to expect and rely on access to the network from anywhere, at any time. Increasingly, people expect similar access to the Web from consumer electronics such as televisions. W3C has begun to organize a series of workshops to discuss this convergence with television industry and other producers of consumer electronics.

The first workshop in the series took place in Japan on 2-3 September. There, 150 participants from various industries discussed key use cases and important requirements for smarter integration of Web, broadcasting and consumer electronics technologies. A summary of the workshop is now available.

One recommendation from the participants was for W3C to create a 'Web and TV' Interest Group. A draft charter is now available; W3C invites public comment.

The proposed scope for the Interest Group is: (1) Minimum clarification about the conceptual relationship between Web and TV, especially the architectural relationship between the services on Web and the TV services; (2) Identification of important requirements for the Web to function effectively with TV services on TV devices and TV-like devices; (3) Identification of important requirements for TV to function effectively on various devices with services on the Web; (4) Review and discussion of deliverables under development by other W3C groups, which touch on the use of the Web and TV; (5) Exploration of barriers to the Web and TV services working on TV devices and TV-like devices, and potential solutions; (6) Provide a forum for the exchange information about Web and TV activities around the world..."

A Location Dereferencing Protocol Using HELD
James Winterbottom, Hannes Tschofenig (et al, eds), IETF Internet Draft

Members of the IETF Geographic Location/Privacy (GEOPRIV) Working Group have published a Standards Track specification for A Location Dereferencing Protocol Using HELD. The document describes how to use the Hypertext Transfer Protocol (HTTP) over Transport Layer Security (TLS) as a dereferencing protocol to resolve a reference to a Presence Information Data Format Location Object (PIDF-LO). The document assumes that a Location Recipient possesses a secure HELD URI that can be used in conjunction with the HELD protocol to request the location of the Target.

From the document Introduction: "Provision of location information by reference involves the creation of a resource that is identified by a 'location URI'. A 'location URI' identifies resource that contains the location of an entity. A location URI might be a temporary resource, created in response to a HTTP-Enabled Location Delivery (HELD). A location URI does not intrinsically include location information, instead the URI is 'dereferenced' by a Location Recipient to acquire location information. This document specifies how a holder of a location URI uses that URI to retrieve location information. The HELD protocol defines a use of HTTP that enables location configuration—the process where a Device acquires location information about itself. A part of location configuration is the provision of a location URI. However, HELD does not describe how such a URI is used; this document provides that definition.

This document defines how HELD is used by a Location Recipient to dereference a location URI and acquire location information. The result of this process is location object in the form of a Presence Information Data Format - Location Object (PIDF-LO) document as defined in RFC 4119. A constrained set of HELD features are defined such that it is suitable for use as a location dereference protocol. Use as a location dereference protocol requires use of the Transport Layer Security (TLS) binding for HTTP in order to provide confidentiality, authentication and protection from modification.

Use of HELD as a dereferencing protocol has the advantage that the Location Recipient can indicate the type of location information it would like to receive. This functionality is already available with the HELD base specification; furthermore, the HELD response from the LIS towards the Location Recipient not only provides the PIDF-LO but also encapsulates supplementary information, such as error messages, back to the Location Recipient. Location URIs created for use with HELD dereferencing use the 'https:' or 'http:' scheme. The behaviour described in this document can be used by Location Recipients that are aware of the fact that the URI is a location URI..."

Revised Working Draft for Widget Updates Specification
Marcos Cáceres, Richard Tibbett, Robin Berjon (eds), W3C Technical Report

Members of the W3C Web Applications Working Group have published a revised Working Draft for Widget Updates, updating the earlier draft of 2010-04-13. This specification is part of the Widgets Family of Specifications. This WD specification takes into account the recommendations from the Widget Updates Patent Advisory Group and considering the large set of prior art the PAG found.

"Widget Updates" defines "a process and a document format to allow a user agent to update an installed widget package with a different version of a widget package. A widget cannot update itself; instead, a widget relies on the user agent to manage the update process. A user agent can perform an update over HTTP and from non-HTTP sources (e.g., directly from a device's memory card or hard disk).

There are a multitude of reasons why authors might want to update a widget including addressing security vulnerabilities, making performance enhancements, and adding new features. Sometimes authors may even want to revert back to a previous version of a widget, if it is found that a newly deployed version of a widget contains issues or vulnerabilities...

To facilitate the process of updating widgets, this specification introduces an XML element, called update-description, that is included into a configuration document of a widget. This specificaiton also introduces a new XML vocabulary, called an update description document. The update-description element provides an author with a means to point to an update description document. If a user agent determines, via the strategies defined in this specification, that two widget packages are not the same version, and if the user consents, the user agent will attempt to replace the currently installed widget package with a potential update. Updates are designed to retain any locally stored data, so to protect end-users from losing data that a widget may have stored at runtime..."

Representing Predictive Solutions in PMML
Alex Guazzelli, IBM developerWorks

"PMML, the Predictive Model Markup Language, is the de facto standard used to represent a myriad of predictive modeling techniques, such as Association Rules, Cluster Models, Neural Networks, and Decision Trees. These techniques empower companies around the globe to extract hidden patterns from data and use them to forecast behavior.

Today, sensors are becoming ubiquitous, from smart meters in homes to the monitoring of equipment and structures such as deep water oil rigs. To make sense of all the data being gathered from these sensors, predictive analytics needs open standards, which allow for systems to communicate without the impediments of proprietary code and incompatibilities. PMML is the standard used to represent predictive analytic or data mining models. With PMML, a predictive solution can be built in one system and deployed in another where it can be put to work immediately.

For the Petroleum and Chemical industry, predictive maintenance is one application in which raw data captured from sensors can be pre-processed and used to build predictive solutions that can detect a machinery breakdown before it happens. In the wake of the Gulf of Mexico tragedy, predictive analytics and open standards can provide yet another tool for ensuring safety and process reliability.

As the de facto standard to represent predictive solutions, PMML allows model and data transformations to be represented together in a single and concise way. When used to represent all the computations that make up a predictive solution, PMML becomes the bridge not only between data analysis, model building, and deployment systems, but also between all the people and teams involved in the analytical process inside a company. This is extremely important, since it can be used to disseminate knowledge and best practices as well as ensure transparency..."

See also: the PMML 4.0 XML Standard


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

Headlines

Sponsors