The Cover PagesThe OASIS Cover Pages: The Online Resource for Markup Language Technologies
Advanced Search
Site Map
CP RSS Channel
Contact Us
Sponsoring CP
About Our Sponsors

Cover Stories
Articles & Papers
Press Releases

XML Query

XML Applications
General Apps
Government Apps
Academic Apps

Technology and Society
Tech Topics
Related Standards
Last modified: June 17, 2010
XML Daily Newslink. Thursday, 17 June 2010

A Cover Pages Publication
Provided by OASIS and Sponsor Members
Edited by Robin Cover

This issue of XML Daily Newslink is sponsored by:
Microsoft Corporation

W3C Call for Implementations: Web Content Transformation Proxies 1.0
Jo Rabin (ed), W3C Technical Report

A Call for Implementations has been issued by W3C in connection with the Candidate Recommendation of Guidelines for Web Content Transformation Proxies 1.0. A 'Candidate Recommendation' is a document that W3C believes has been widely reviewed and satisfies the Working Group's technical requirements; W3C publishes a Candidate Recommendation to gather implementation experience. This document was developed by the W3C Mobile Web Best Practices Working Group as part of the Mobile Web Initiative. No feature has been identified as at risk at this point, and the Working Group does not plan to request to advance to Proposed Recommendation prior to 17-August-2010. A companion 'Test Suite' document has been developed so as to have a test case for every testable assertion in the specification.

This specification "provides guidance to Content Transformation proxies as to whether and how to transform Web content. Content Transformation proxies alter requests sent by user agents to servers and responses returned by servers so that the appearance, structure or control flow of Web applications are modified. Content Transformation proxies are mostly used to convert Web sites designed for desktop computers to a form suitable for mobile devices. Based on current practice and standards, this document specifies mechanisms with which Content Transformation proxies should make their presence known to other parties, present the outcome of alterations performed on HTTP traffic, and react to indications set by clients or servers to constrain these alterations. The objective is to reduce undesirable effects on Web applications, especially mobile-ready ones, and to limit the diversity in the modes of operation of Content Transformation proxies, while at the same time allowing proxies to alter content that would otherwise not display successfully on mobile devices. Important considerations regarding the impact on security are highlighted... The W3C Mobile Web Best Practices Working Group neither approves nor disapproves of Content Transformation, but recognizes that is being deployed widely across mobile data access networks. The deployments are widely divergent to each other, with many non-standard HTTP implications, and no well-understood means either of identifying the presence of such transforming proxies, nor of controlling their actions...

This Candidate Recommendation is the result of extensive and lively discussions, both within the group and with external reviewers, triggered by the unique position of content transformation proxies in the middle of the delivery chain. The group believes that the specification provides a valuable balance between the needs and concerns of the parties whose contents need to go through such proxies (end users, content providers, network operators) but points out that it is unlikely to be the final word on the topic

A test case repository has been created to collect test cases that may be used to assess whether an implementation follows the guidelines or not. Due to the nature of the guidelines, not all of them may be easily tested. Instead of a complete suite of tests that would cover each and every aspect of the specification, the Mobile Web Best Practices Working Group expects this repository to contain a series of challenge test cases on assertions for which such challenges may be created. The Working Group will initiate the work on this test suite during the Candidate Recommendation phase but expects the repository to grow over time based on contributions from the community..."

See also: the Web Content Transformation Proxies Test Suite specification

Apache Tuscany Project Announces SCA Java Travel Sample 1.0 Version 1.0
Simon Nash, Apache Tuscany Project Announcement

Members of the Apache Tuscany Project team have announced the version 1.0 release of the Java SCA Travel Sample. The travel sample consists of a number of scenarios which demonstrate various aspects of SCA and Apache Tuscany in the context of a travel booking application.

Concurrently, the Apache Tuscany Project announced the fifth milestone release of the Tuscany SCA 2.0 project. Apache Tuscany/SCA provides a runtime environment based on Service Component Architecture (SCA), which is a set of OASIS specifications aimed at simplifying SOA application development. The main features of this fifth 2.0 milestone release are: (1) Passes the OASIS conformance test suite for the SCA Assembly, SCA-J CAA and SCA-J CI Specifications; (2) Passes OSGI remote service SCA config type conformance test suite; (3) New Tuscany specific support for REST/JAXRS; (4) Started improving the layout of the samples to separate contributions from launchers; (5) Further improvements to the distributed SCA domain support; (6) Improved support for the SCAClient in distributed scenarios; (7) Dropped support for JDK 5; (8) Numerous other bug fixes and improvements.

The Apache Tuscany SCA Travel Sample shows how Apache Tuscany SCA can be used in a business application. Unlike other Apache Tuscany SCA samples that are included in the Apache Tuscany SCA distribution, the travel sample is released as a separate package. This matches how user applications are developed and makes it easier for Apache Tuscany users to use the travel sample as a template for developing and packaging their own applications.

The travel sample distribution contains source code and build files for the travel sample, together with binary dependencies of the travel sample that aren't included in the Apache Tuscany SCA Java binary distribution. The distribution doesn't include binaries for the travel sample because one of the major purposes of this sample is to show users how to build and run an Apache Tuscany application from source code..."

See also: the OASIS Open Composite Services Architecture (CSA) Member Section

Request by Reference Version 1.0 for OAuth 2.0
Nat Sakimura (ed), IETF Internet Draft

An initial level -00 Internet Draft has been published for the IETF Standards Track specification Request by Reference ver.1.0 for OAuth 2.0. The document defines a simple mechanism of making request by reference in OAuth 2.0. The reference is given as URL and request parameters are defined as JSON object which is pointed by the URL.

Use cases are presented as follows. "1. When the User Agent looks like it would not like long URLs: It is entirely possible that some extension makes a long URL. For example, the client might want to send a public key with the request. 2. When the server wants the request non-repudiation: The server might want the request to be non-repudiable. It is possible to sign the request dynamically, but a simpler way of doing it is to make a signed request file and put it on the client. It can just be done by a client utility or something, so that the private key does not even have to reside on the server nor the client needs to program anything...

Or: 3. When the server wants the requests to be cacheable: If the 'request_url' comes with sha256 hash as defined in FIPS180-2 of the file, the server knows if the file has changed without fetching it, so it does not have to re-fetch a same file, which is a win as well. 4. When the client wants to simplify the implementation without compromising the security: If the request parameters go through the Browser, it may be tampered at the browser even if TLS was used. This implies we need to have signature on the request as well. However, if HTTPS 'request_url' was used, it is not going to be tampered, thus we now do not have to sign the request. This simplifies the implementation...

As to formats: (1) JSON OAuth Request: The OAuth authorization request parameters are included in the entity body of the HTTP response using the 'application/json' media type as defined by JSON per RFC 4627. It MAY include any other parameters as well. The parameters are serialized into a JSON structure by adding each parameter at the highest structure level. Parameter names and string values are included as JSON strings. Numerical values are included as JSON numbers. (2) Signed JSON OAuth Request: To achieve non-repudiation and ascertained provenance of the JSON OAuth Request when it was obtained through unprotected channel, one MAY use asymmetric signature as in 'magic_signatures'... (3) Encrypted Format: The HTTP response may be encrypted by the receiving party's public key for audience restriction and confidentiality. If it is encrypted, the data is formatted as a JSON Encryption Envelope..."

See also: the IETF Open Authentication Protocol (OAuth) Working Group

Session Peering Provisioning Protocol (SPPP) Over SOAP and HTTP
Kenneth Cartwright (ed), IETF Internet Draft

An initial level -00 IETF Internet Draft has been published for the Standards Track specification SPPP Over SOAP and HTTP. From the Abstract: The Session Peering Provisioning Protocol (SPPP) is an XML protocol that exists to enable the provisioning of session establishment data into Session Data Registries or SIP Service Provider data stores. Sending XML data structures over Simple Object Access Protocol (SOAP) and HTTP(s) is a widely used, de-facto standard for messaging between elements of provisioning systems. Therefore the combination of SOAP and HTTP(s) as a transport for SPPP is a natural fit. The obvious benefits include leveraging existing industry expertise, leveraging existing standards, and a higher probability that existing provisioning systems can be more easily integrated with this protocol. This document describes the specification for transporting SPPP XML structures over SOAP and HTTP(s)...

SPPP, as defined in the 'Session Peering Provisioning Protocol', is best supported by a transport and messaging infrastructure that is connection oriented, request-response oriented, easily secured, supports propagation through firewalls in a standard fashion, and that is easily integrated into back-office systems. This is the type of environment that inter-organization provisioning transactions typically take place. Given the current state of industry practice and technologies, SOAP and HTTP(s) are ideal for this type of environment. This document describes the specification for transporting SPPP XML structures over SOAP and HTTP(s).

The specification in this document for transporting SPPP XML structures over SOAP and HTTP(s) is primarily comprised of five subjects: (1) a description of any applicable SOAP features, (2) any applicable HTTP features, (3) authentication and session management, (4) security considerations, and perhaps most importantly, (5) the Web Services Description Language (WSDL) definition.

The list of SOAP features that are explicitly used and required for SPPP are limited. Most SOAP features are not necessary for SPPP. SPPP primarily uses SOAP simply as a standard message envelope technology. The SOAP message envelope is comprised of the SOAP header and body. As described in the SOAP specifications, the SOAP header can contain optional, application specific, information about the message... The WSDL definition for the SPPP SOAP messages imports by reference the XML data types contained in the SPPP schema. The IANA registry where the SPPP schema resides is described in The IETF XML Registry (RFC 3688). The SOAP WSDL best practice for this type of application is what is often referred to as the Document Literal Wrapped style of designing SOAP WSDL. This style is generally regarded as an optimal approach that enhances maintainability, comprehension, portability, and, to a certain extent, performance..."

See also: the IETF Data for Reachability of Inter/tra-NetworK SIP (DRINKS) Working Group

Voice Extensible Markup Language (VoiceXML) 3.0
Scott McGlashan, Daniel Burnett, Rahul Akolkar (et al., eds.) W3C Technical Report

Members of the W3C Voice Browser Working Group have published a revised Working Draft for Voice Extensible Markup Language (VoiceXML) 3.0. VoiceXML 3.0 is a modular XML language for creating interactive media dialogs that feature synthesized speech, recognition of spoken and DTMF key input, telephony, mixed initiative conversations, and recording and presentation of a variety of media formats including digitized audio, and digitized video... The main differences from the previous draft are described in Appendix F, and a diff-marked version of this document is available for comparison purposes; changes include: added Timer resource; added Real Time Controls module; added Transition Controller module; updated text of Recognition Resource to support SIV processing updated Initialization to separate DOM processing from property lookup...

The document explains the core of VoiceXML 3.0, an extensible framework that describes how semantics are defined, how syntax is defined and how the two are connected together. In this document, "semantics" means both SCXML and/or textis means behavior represented as English text, SCXML syntax and/or state charts diagram. definitions of core functionality, such as might be used by an implementer of VoiceXML 3.0. The term "syntax" refers to XML elements and attributes that are an application author's programming interface to the functionality defined by the "semantics".

Within this document, all the functionality of VoiceXML 3.0 is grouped into modules of related capabilities. Modules can be combined together to create complete profiles (languages). This document describes how to define both modules and profiles. Modules can be combined together to create complete profiles (languages). This document describes how to define both modules and profiles. In addition to describing the general framework, this document explicitly defines a broad range of functionality, several modules and two profiles...

Specification status: "This 17-June-2010 document is very much a work in progress. Many sections are incomplete, only stubbed out, or missing entirely. To get early feedback, the group focused on defining enough functionality, modules, and profiles to demonstrate the general framework. To complete the specification, the group expects to introduce additional functionality (for example speaker identification and verification, external eventing) and describe the existing functionality at the level of detail given for the Prompt and Field modules. We explicitly request feedback on the framework, particularly any concerns about its implementability or suitability for expected applications. By late 2010 the group expects all key capabilities to be present in the specification, with details worked out by early 2011...."

See also: the W3C Voice Browser Activity

IBM EGL Business Language Moves to Open Source
Paul Krill, InfoWorld

"IBM has unveiled plans for an open source Eclipse project based on the company's EGL business application programming language, in an effort to boost backing for EGL. The project has been labeled EGL (Enterprise Generation Language) Development Tools Project and was submitted to the Eclipse Foundation. EGL itself will be open-sourced as well.

EGL is a modeling language that borrows from Unified Modeling Language. It is designed for building portable, cross-platform applications and services that can be deployed to runtime environments based on the evolving needs of business. Eclipse was selected as the home for the EGL open source project because EGL tools already are built on Eclipse and EGL integrates with other Eclipse technologies such as BIRT (Business Intelligence and Reporting Tools), Web Tools, and Data Tools)..."

According to the EGL Development Tools Project Proposal: "EGL is a programming language conceptually similar to many common languages that have come before it. The language borrows concepts familiar to anyone using statically typed languages like Java, COBOL, C, etc. However, it borrows a concept from UML (Universal Modeling Language) that is not typically found in statically typed programming language—the concept of Stereotype. In UML, stereotypes are used to tag UML elements with metadata (in this case, metadata refers to information about the UML element, for example, information about a UML element called a "class"). Constraints can be defined by stereotype definitions such that elements stereotyped by the given stereotype must adhere to the defined constraints of that stereotype. Stereotypes in UML are used as a lightweight mechanism to extend the standard modeling concepts. Stereotypes in EGL are essentially the same idea and are used to extend the basic EGL core language concepts...

EGL code is not executed directly as byte or machine code, but is instead compiled and generated into either Java (e.g. Java-based Web services that access information in databases), JavaScript (e.g., RIAs that utilize Dojo and other JavaScript libraries), or COBOL source code depending on the desired target runtime environment (the generator is sensitive to both resulting source code language and resulting runtime environment in which that code will run). Being able to deploy the same EGL code to multiple environments enables ultimate platform flexibility, and breaks the barrier that today forces use of specific languages when developing for specific platforms. Portability is especially useful for businesses that currently deploy applications across a wide array of environments ranging from web browsers on client machines, to JEE on mid-tier application servers, to mainframe servers such as CICS or IMS... A technology such as EGL allows the creation of applications that are able to be re-hosted across changing runtime environments without changing the source code. Instead changes to the model generators can either apply existing concepts to the new infrastructure or to allow the programmers to more easily apply new concepts on the new platform..."

See also: the EGL Development Tools Project Proposal

CSC Launches Cloud Collaboration, SaaS
Charles Babcock, InformationWeek

"CSC, one of the few remaining independent outsourcing vendors in the United States, is launching CloudLab and CloudExchange as services available through its global network of data centers. Falls Church, Va.-based CSC, also known as Computer Sciences Corp., has 94,000 employees, revenue in fiscal 2010 of $16.1 billion, and seven data centers around the world. These data centers pre-dated the cloud products but are now 'cloud-enabled' to offer CloudLab and CloudExchange, Siki Giunta said in an interview. In the United States, CSC has data centers in Chantilly, Va., Newark, Del., and Chicago, Ill. The others are found in Sydney, Australia; Copenhagen, Denmark; New Kent Complex, U.K.; and Luxembourg...

CloudLab is software-as-a-service providing a scalable software development, testing, and quality assurance facility. It allows for precisely configured test environments, while providing a secure, controlled-access environment in which to conduct new software development and testing. CloudLab can also be used by sales force members for producing software product demonstrations... CSC also announced a three-year plan, the Trusted Cloud Services roadmap. This summer CSC will bring out an approach to virtual desktop implementations, a security solution for e-mail and software-as-a-service applications..."

From the text of the announcement: "CloudExchange provides for large-scale email services, including instant messaging and video, and collaboration services, including calendar, document sharing and spreadsheets. CloudExchange accommodates the mobile workforce, enabling employees anywhere to work together to complete a presentation, proposal or contract in real-time while holding a video chat. By using the solution, clients benefit from industry-leading service levels, reduced administrative overhead, and improved collaboration, increasing productivity and lowering costs...

CSC also announced CSC Gateway, an e-commerce portal for hosting and cloud services clients that simplifies and speeds access to CSC solutions and includes self-managing features such as auto-provisioning, pay-per-use and electronic purchase orders. Clients can now tap into the complete catalog of CSC's Trusted Cloud and Hosting solutions through an intuitive, easy-to-use interface..."

See also: the CSC announcement


XML Daily Newslink and Cover Pages sponsored by:

IBM Corporation
ISIS Papyrus
Microsoft Corporation
Oracle Corporation

XML Daily Newslink:
Newsletter Archive:
Newsletter subscribe:
Newsletter unsubscribe:
Newsletter help:
Cover Pages:

Hosted By
OASIS - Organization for the Advancement of Structured Information Standards

Sponsored By

IBM Corporation
ISIS Papyrus
Microsoft Corporation
Oracle Corporation


XML Daily Newslink
Receive daily news updates from Managing Editor, Robin Cover.

 Newsletter Subscription
 Newsletter Archives
Globe Image

Document URI:  —  Legal stuff
Robin Cover, Editor: