Cover Pages: XML Daily Newslink: Tuesday, 05 January 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

W3C Last Call Public Review for XProc: An XML Pipeline Language
UN/CEFACT Approves CCTS 3.0 and Core Components Data Type Catalogue 3.0
OASIS Members Release Proposed Charter for Identity In the Clouds TC
Proposed IETF Working Group for Internet Wideband Audio Codec
Updated Working Draft Specification for an Indexed Database API
A SIP Event Package for Subscribing to Changes to an HTTP Resource

W3C Last Call Public Review for XProc: An XML Pipeline Language
Norman Walsh, Alex Milowski, Henry Thompson (eds), W3C Technical Report

Members of the W3C XML Processing Model Working Group have released a Last Call Working Draft for the specification of XProc: An XML Pipeline Language. The Working Group believes that this specification is complete and finished; the review period ends on 02-February-2010. The Working Group is returning the specification to Last Call in order to get community review of a number of significant changes motivated by comments on previous working drafts, including: rules for versioning, which have been completely rewritten; a version attribute is now mandatory on some top-level elements; XProc now supports a conditional element exclusion mechanism; the rules for connections in 'p:with-option' and 'p:with-param' have been relaxed; the rules for connections of primary parameter input ports have been relaxed, etc.

XProc is a language for describing operations to be performed on XML documents. An XML Pipeline specifies a sequence of operations to be performed on a collection of XML input documents. Pipelines take zero or more XML documents as their input and produce zero or more XML documents as their output. A pipeline consists of steps. Like pipelines, steps take zero or more XML documents as their inputs and produce zero or more XML documents as their outputs. The inputs of a step come from the web, from the pipeline document, from the inputs to the pipeline itself, or from the outputs of other steps in the pipeline. The outputs from a step are consumed by other steps, are outputs of the pipeline as a whole, or are discarded.

There are three kinds of steps: atomic steps, compound steps, and multi-container steps. Atomic steps carry out single operations and have no substructure as far as the pipeline is concerned. Compound steps and multi-container steps control the execution of other steps, which they include in the form of one or more subpipelines..."

UN/CEFACT Approves CCTS 3.0 and Core Components Data Type Catalogue 3.0
Staff, UN/CEFACT Applied Technologies Group (ATG) Announcement

"The United Nations Centre for Trade Facilitation and Electronic Business (UN/CEFACT), a Working Party of the United Nations Economic Commission for Europe, has approved version 3.0 of two important standards that are used to develop data definitions for use across industries, across across applications and across different hardware/computer platforms. These new versions incorporate five years of lessons learned from a wide variety of implementers using earlier versions and are based on business requirements from different industries and stakeholders in both the private and public sectors.

The Core Components Technical Specification (CCTS) version 3.0 defines the rules for building core components which are building blocks for use in databases, data models and data exchange. Core components define format and the semantic (linguistic) meaning of data using the rules in the CCTS to build units of data ranging from basic concepts to more complex ones (for example from 'postal code' to 'address' to 'customer address' ). The new CCTS version 3.0 will enhance the development and use of these common semantic building blocks... CCTS v3.0 addresses the problem of the lack of information interoperability, and is particularly well suited for enabling cross-industry interoperability. Core components based on CCTS v3.0 provide conceptual and logical data models that are completely syntax ('message' structure) neutral and independent. CCTS is well suited for creating new business vocabularies as well as restructuring existing business vocabularies to achieve true semantic interoperability of data...

Together with CCTS v3.0, UN/CEFACT has approved the Core Components Data Type Catalogue Version 3.0. This Catalogue defines the types of data (i.e., value domains) for basic data elements and is the key to ensuring that the core components designed using CCTS 3.0 are logical data models and completely syntax independent. The release version 3.0 of the CCTS Data Type Catalogue and the Core Components Technical Specification as well as the ongoing work on the Core Components Library within the UN/CEFACT Forum, was welcomed by a broad number of supporting governments, Standards Development Organizations, private sector companies, and solution providers who actively contribute to the development and implementation of core components standards known as the CCTS Common Methodology Standards Stack..."

OASIS Members Release Proposed Charter for Identity In the Clouds TC
Staff, OASIS Announcement

Representatives from Red Hat, CA, and OASIS individual members have submitted a charter proposal for formation of a new 'OASIS Identity In the Clouds Technical Committee'.

According to the Statement of Purpose: "Cloud Computing is turning into an important IT service delivery paradigm. Many enterprises are experimenting with cloud computing, using clouds in their own data centers or hosted by third parties, and increasingly they deploy business applications on such private and public clouds. Cloud Computing raises many challenges that have serious security implications. Identity Management in the clouds is such a challenge. Many enterprises avail themselves of a combination of private and public Cloud Computing infrastructures to handle their workloads. In a phenomenon known as 'Cloud Bursting', the peak loads are offloaded to public Cloud computing infrastructures that offer billing based on usage. This is a use case of a Hybrid Cloud infrastructure. Additionally, governments around the world are evaluating the use of Cloud Computing for government applications. For instance, the US Government has started apps.gov to foster the adoption of Cloud Computing. Other governments have started or announced similar efforts.

The purpose of the OASIS Identity in the Clouds TC is to collect and harmonize definitions, terminologies and vocabulary of Cloud Computing... The TC will collect use cases to help identify gaps in existing Identity Management standards. The uses cases will be used to identify gaps in current standards and investigate the need for profiles for achieving interoperability with in current standards..."

A draft of the proposed TC charter has been published for comment by OASIS members through 2010-01-19.

Proposed IETF Working Group for Internet Wideband Audio Codec
Staff, Internet Engineering Steering Group

A posting from the Internet Engineering Steering Group Secretary announces a proposal for a new working group in the IETF Real-time Applications and Infrastructure Area. The IESG has not made any determination as yet, and invites public comment on the draft charter by January 20, 2010.

The proposed 'Internet Wideband Audio Codec (CODEC)' working group would develop a single high-quality audio codec that is optimized for use over the Internet and that can be widely implemented and easily distributed among application developers, service operators, and end users.

Core technical considerations include, but are not necessarily limited to, the following: (1) Designing for use in interactive applications — examples include, but are not limited to, point-to-point voice calls, multi-party voice conferencing, telepresence, teleoperation, in-game voice chat, and live music performance; (2) Addressing the real transport conditions of the Internet as identified and prioritized by the working group; (3) Ensuring interoperability with the Real-time Transport Protocol (RTP), including secure transport via SRTP; (4) Ensuring interoperability with Internet signaling technologies such as Session Initiation Protocol (SIP), Session Description Protocol (SDP), and Extensible Messaging and Presence Protocol (XMPP); however, the result should not depend on the details of any particular signaling technology..."

Problem Statement: "According to reports from developers of Internet audio applications and operators of Internet audio services, there are no standardized, high-quality audio codecs that meet all of the following three conditions: [i] Are optimized for use in interactive Internet applications. [ii] Are published by a recognized standards development organization (SDO) and therefore subject to clear change control. [iii] Can be widely implemented and easily distributed among application developers, service operators, and end users. There exist codecs that provide high quality encoding of audio information, but that are not optimized for the actual conditions of the Internet; according to reports, this mismatch between design and deployment has hindered adoption of such codecs in interactive Internet applications...

Lack of standardization and clear change control has hindered adoption of such codecs in interactive Internet applications. There exist codecs that are standardized, but that cannot be widely implemented and easily distributed; according to reports, the presence of various usage restrictions (e.g., in the form of requirements to pay royalty fees, obtain a license, enter into a business agreement, or meet other special conditions imposed by a patent holder) has hindered adoptions of such codecs in interactive Internet applications..."

Updated Working Draft Specification for an Indexed Database API
Nikunj Mehta (ed), W3C Technical Report

Members of the W3C Web Applications Working Group have published a revised Working Draft for the Indexed Database API specification. It "defines APIs for a database of records holding simple values and hierarchical objects. Each record consists of a key and some value. Moreover, the database maintains indexes over records it stores. An application developer directly uses an API to locate records either by their key or by using an index. A query language can be layered on this API. An indexed database can be implemented using a persistent B-tree data structure...

User agents need to store large numbers of objects locally in order to satisfy off-line data requirements of Web applications. The W3C "Web Storage" specification is useful for storing pairs of keys and their corresponding values. However, it does not provide in-order retrieval of keys, efficient searching over values, or storage of duplicate values for a key.

The Indexed Database API specification provides a concrete API to perform advanced key-value data management that is at the heart of most sophisticated query processors. It does so by using transactional databases to store keys and their corresponding values (one or more per key), and providing a means of traversing keys in a deterministic order. This is often implemented through the use of persistent B-tree data structures that are considered efficient for insertion and deletion as well as in-order traversal of very large numbers of data records..."

A SIP Event Package for Subscribing to Changes to an HTTP Resource
Adam Roach (ed), IETF Internet Draft

IETF has published a revision of the specification for A SIP Event Package for Subscribing to Changes to an HTTP Resource. It proposes a mechanism, based on the SIP events framework, for near-real-time ability to discover when a specific HTTP resource is created, changed, or deleted.

The Session Initiation Protocol (SIP) defined in RFC 3261 is increasingly being used in systems that are tightly coupled with Hypertext Transport Protocol (HTTP) servers for a variety of reasons. In many of these cases, applications can benefit from learning of changes to specified HTTP resources in near-real-time. For example, user agent terminals may elect to store service-related data in an HTTP tree. When such configuration information is stored and retrieved using HTTP, clients may need to be informed when information changes, so as to make appropriate changes to their local behavior and user interface.

This document defines a mechanism, based on the SIP Event Framework, for subscribing to changes in the resource referenced by an HTTP server. Such subscriptions do not necessarily carry the content associated with the resource. In the cases that the content is not conveyed, the HTTP protocol is still used to transfer the contents of HTTP resources. This document further defines a mechanism by which the proper SIP and/or SIPS URI to be used for such subscriptions can be determined from the HTTP server.

One of the key challenges in subscribing to the changes of a resource indicated by an HTTP URL is determining which SIP URI corresponds to a specific HTTP URL. This specification takes the approach of having the HTTP server responsible for the URL in question select an appropriate SIP URI for the corresponding resource, and to return that URI within an HTTP transaction. In particular, HTTP servers use link relations -- such as the HTTP Link: header field, the HTML 'link' element, and the Atom 'atom:link' element — to convey the URI or URIs that can be used to discover changes to the resource. This document defines two new link relation types ("monitor" and "monitor-group") for this purpose, and specifies behavior for SIP and SIPS URIs in link relations of these types..."


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

Headlines

Sponsors