Cover Pages: XML Daily Newslink: Monday, 04 August 2008

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:
Primeton http://www.primeton.com

Headlines

W3C Issues Call for Implementations of CSS Mobile Profile 2.0
Defining the Value of CCXML: VoiceXML Featured Article
Extensible Markup Language (XML) Format Extension for Representing Copy Control Attributes in Resource Lists
A Document Format for Requesting Consent
Cloud Computing With Amazon Web Services
How Comet Brings Instant Messaging to meebo
OASIS Solution Deployment Descriptor Specification 1.0
The Limited Lifetime Ubiquitous Protocol (LLUP) Specification
FXStruts: Developing Flex-Friendly Struts Application

W3C Issues Call for Implementations of CSS Mobile Profile 2.0
Svante Schubert (ed), W3C Technical Report

Members of the W3C CSS Working Group have released the "CSS Mobile Profile 2.0" specification as a Candidate Recommendation. A W3C "Candidate Recommendation" is a document that has been widely reviewed and ready for implementation; W3C encourages everybody to implement this specification and return comments to the public archived mailing list. In order to exit the Candidate Recommendation phase, the following criteria must be satisfied: (1) A minimum of six months of the CR period must be elapsed to ensure that enough time is given for providing implementation feedback. (1) At least two implementations of all the required features of this specification. The "CSS Mobile Profile 2.0" specification defines a common baseline of CSS support that even constrained mobile devices can provide. This CSS effort is part of W3C's ongoing efforts to make the Web easier to use from a mobile devices. For the CSS Mobile Profile 2.0, W3C has worked closely together with OMA to remove the differences between W3C's and OMA's previous CSS-mobile profiles. An "alpha" quality test suite is available for the mobile profile. The Working Group will track implementations during the Candidate Recommendation phase. Summary: "This specification defines in general a subset of CSS 2.1 that is to be considered a baseline for interoperability between implementations of CSS on constrained devices (e.g. mobile phones). Its intent is not to produce a profile of CSS incompatible with the complete specification, but rather to ensure that implementations that due to platform limitations cannot support the entire specification implement a common subset that is interoperable not only amongst constrained implementations but also with complete ones. Additionally, this specification aligns itself as much as possible with the OMA Wireless CSS 1.1 specification. At the same time, OMA is doing alignment work in OMA Wireless CSS 1.2."

See also: the Mobile Web news item

Defining the Value of CCXML: VoiceXML Featured Article
Greg Galitzine, TCMNet IRV

In this article, Greg Galitzine interviews RJ Auburn, Voxeo Chief Technology Officer (also: Chair of the W3C CCXML Working Group) about the role of CCXML and the value it brings to developers. CCXML (Call Control Extensible Markup Language) is the W3C standard markup language for controlling how phone calls are placed, answered, transferred, conferenced, and more. CCXML is often mentioned in close proximity to its sister standardVoiceXML. Together the two standards provide a 100 percent standards- and XML-based solution for any telephony application. While VoiceXML addresses the voice interface and the user interface, CCXML focuses on the call control functionality (answering phone calls, redirecting phone calls, call transfers and so on). The standards complement each other to address different parts of a telephony application. Auburn: "CCXML is the missing piece to creating applications for the phone using Web technologies and using XML. Traditionally you could do things on a protocol level, but you would have to understand the details of the specific telephony protocol you were working with. There was simply no good standard that was simple to implement across different environments. If you were creating an application in say SIP, there wouldn't necessarily be a good way to map that into the ISDN world... Using CCXML makes it simpler for developers who might have limited knowledge of telephony. CCXML takes the same Web-based approach that VoiceXML did to create voice applications. It uses the same founding principles to make it easier for application developers to use Web technologies and apply those to the call control side. It makes it easier for someone who doesn't know a lot about telephony—someone who maybe has a bit of Web experience—to go in and create applications using CCXML to place an outbound call campaign, to manage telephone connections, and so on. Most of the major platform vendors have adopted CCXML as the standard for doing call control: everyone from Voxeo to IBM, Nortel, Genesys... It's being used to create all sorts of applications from outbound notification systems or appointment reminder systems or school notification systems... to more complicated use cases, such as session border controllers in the SIP world, or back to back user agents. Using CCXML, it's easy to create applications and functionality that would be rather difficult to develop at the SIP level..." Note: W3C "Voice Browser Call Control: CCXML Version 1.0" is designed to provide telephony call control support for dialog systems, such as VoiceXML. While CCXML can be used with any dialog systems capable of handling media, CCXML has been designed to complement and integrate with a VoiceXML interpreter. Because of this there are many references to VoiceXML's capabilities and limitations. There are also details on how VoiceXML and CCXML can be integrated. However, it should be noted that the two languages are separate and are not required in an implementation of either language. For example, CCXML could be integrated with a more traditional Interactive Voice Response (IVR) system or a 3GPP Media Resource Function (MRF), and VoiceXML or other dialog systems could be integrated with other call control systems.

See also: W3C CCXML

Extensible Markup Language (XML) Format Extension for Representing Copy Control Attributes in Resource Lists
Miguel A. Garcia-Martin and Gonzalo Camarillo (eds), IETF Internet Draft

Members of the IETF Session Initiation Proposal Investigation (SIPPING) Working Group have published an Internet Draft specification for "Extensible Markup Language (XML) Format Extension for Representing Copy Control Attributes in Resource Lists." In certain types of multimedia communications, a Session Initiation Protocol (SIP) request is distributed to a group of SIP User Agents (UAs). The sender sends a single SIP request to a server which further distributes the request to the group. This SIP request contains a list of Uniform Resource Identifiers (URIs), which identify the recipients of the SIP request. This URI-list is expressed as a resource list XML document. This specification defines an XML extension to the XML resource list format that allows the sender of the request to qualify a recipient with a copy control level similar to the copy control level of existing e-mail systems. Although the XML resource list (RFC 4826) provides a powerful mechanism for describing a list of resources, there is a need for a copy control attribute to determine whether a resource is receiving a SIP request as a primary recipient, a carbon copy, or a blind carbon copy. This is similar to common e-mail systems, where the sender can categorize each recipient as To, Cc, or Bcc recipient. This document addresses this problem by providing an extension to the XML resource list (RFC 4826) that enables the sender to supply a copy control attribute that labels each recipient as a "to", "cc", or "bcc" recipient. This attribute indicates whether the recipient is receiving a primary copy of the SIP request, a carbon copy, or a blind carbon copy. Additionally, we provide the sender with the capability of indicating in the URI-list that one or more resources should be anonymized, so that some recipients' URIs are not disclosed to the other recipients. Instead, these URIs are replaced with anonymous URIs.

A Document Format for Requesting Consent
Gonzalo Camarillo, IETF Internet Draft

The framework for consent-based communications in the Session Initiation Protocol (SIP) identifies the need for a format to create permission documents. Such permission documents are used by SIP (RFC 3261) relays to request permission to perform translations. A relay is defined as any SIP server, be it a proxy, B2BUA (Back-to-Back User Agent), or some hybrid, which receives a request and translates the request URI into one or more next hop URIs to which it then delivers a request. The format for permission documents specified in this document is based on Common Policy (RFC 4745), an XML document format for expressing privacy preferences. This document defines an Extensible Markup Language (XML) format for a permission document used to request consent. A permission document written in this format is used by a relay to request a specific recipient permission to perform a particular routing translation.

Cloud Computing With Amazon Web Services
Prabhakar Chaganti, IBM developerWorks

Cloud computing can be loosely defined as using scalable computing resources provided as a service from outside your environment on a pay-per-use basis. You use only what you need, and pay for only what you use. You can access any of the resources that live in the "cloud" at any time, and from anywhere across the Internet. You don't have to care about how things are being maintained behind the scenes in the cloud. Cloud computing derives from the common depiction in technology architecture diagrams of the Internet, or IP availability, illustrated as a cloud. Cloud computing gained attention in 2007 as it became a popular solution to the problem of horizontal scalability. The cloud is responsible for being highly available and responsive to the needs of your application. Cloud computing has also been called utility computing, or grid computing. Cloud computing is a paradigm shift in how we architect and deliver scalable applications... With cloud computing, excess computing capacity can be put to use and be profitably sold to consumers. This transformation of computing and IT infrastructure into a utility, which is available to all, somewhat levels the playing field. It forces competition based on ideas rather than computing resources... Amazon Web Services are a set of services that provide programmatic access to Amazon's ready-to-use computing infrastructure. The robust computing platform that was built and refined over the years by Amazon is now available to anyone who has access to the Internet. Amazon provides several different Web services, but this series will focus only on the basic building block services that fulfill some of the core needs of most systems: storage, computing, messaging, and datasets. Amazon Simple Queue Service (SQS) provides access to the reliable messaging infrastructure used by Amazon. You can send and retrieve messages from anywhere using simple REST-based HTTP requests. Nothing to install, nothing to be configured. You can create an unlimited number of queues, and send an unlimited number of messages. The messages are stored by Amazon across multiple servers and data centers to provide the redundancy and reliability you need from a messaging system. Each message can contain up to 8KB of text data... Each queue can have a configurable visibility timeout, which is used to control access to the queue by multiple readers. Once an application reads a message from the queue, the message will not be visible to any other readers until the timeout period expires. The message will reappear in the queue after the timeout period has expired, and then it can be handled by another reader process. SQS integrates very well with the other Amazon Web Services. It provides a great way to build a decoupled system where your EC2 instances can communicate with each other by sending messages to SQS and coordinate the workflow. You can also use the queues for building a self-healing, auto-scaling EC2-based infrastructure for your application. You can secure the messages in your queue against unauthorized access by using the authentication mechanisms provided by SQS...

How Comet Brings Instant Messaging to meebo
Howard Wen, O'Reilly Technical

Instant messaging has become a ubiquitous communications feature of the internet. Yet it has been mainly confined to requiring the user to download, install and run a separate application. Prior to the launch of meebo [a communications and media company], the concept of an in-browser instant messenger had not been executed well enough to match the features, responsiveness and stability of a standalone messenger program. As meebo was being built, the technology goal was very simple: the Web site-driven instant messenger service had to work across as many platforms (varieties of browsers, operating systems, and networks) as possible. It had to be extremely responsive. It had to give the user an online communications experience similar to, and as flawless as, that of a standalone instant messaging application. Instant messaging sets a very high bar when it comes to responsiveness, because the term "instant" implies and the user expects just that. As [Meebo's Jian] Shen explains, "Most users are not aware of Web browser limitations and don't care. If a site advertises instant messaging as a capability, the user is going to expect to send and, more importantly, receive messages in near real-time." Comet powers the "instant" aspect for instant messaging on the Web The ability to create an "instant" communications experience through the Web is the strength of the Comet recipe. The use of long-polling via the XMLHttpRequest is a critical technology to meebo. It enabled meebo to implement low-latency bi-directional communication on any modern computer that can access the Web, without the need to download software... Requests are not expected to return immediately but rather within a specified, longer time-out window (like one minute), hence the "long" in "long-polling." "The 'polling' part refers to the fact that when we receive a response from an XMLHttpRequest, the server closes that connection, and we launch another request immediately afterward—hence, another 'poll' on the server—for another longer than usual time-out window, again something like one minute... The meebo service works with the IM networks of AOL, Yahoo, Microsoft, Google, ICQ, and Jabber.

See also: the meebo web site

OASIS Solution Deployment Descriptor Specification 1.0
Julia McCarthy, Robert Dickau, Merri Jensen (eds), OASIS Candidate OS

Members of the OASIS Solution Deployment Descriptor (SDD) Technical Committee have submitted an approved Committee Specification for consideration as an OASIS Standard. Balloting on the CS will begin on August 16, 2008 and end on August 31. "Solution Deployment Descriptor Specification 1.0" defines a standard, in the form of a schema for XML documents, called Solution Deployment Descriptors, or SDDs. SDDs define metadata that describes the packaging and deployment characteristics of resources that are relevant for their lifecycle management, including creation, configuration and maintenance... The specification defines schema for two XML document types: Package Descriptors and Deployment Descriptors. Package Descriptors define characteristics of a package used to deploy a solution. Deployment Descriptors define characteristics of the content of a solution package, including the requirements that are relevant for creation, configuration and maintenance of the solution content. The semantics of the descriptors are fully defined, allowing software implementations to precisely understand the intent of the descriptor authors and to use the information provided in the descriptors to support solution deployment. The Global Grid Forum Application Content Service has agreed to adopt the SDD PackageDescriptor (by reference) as their software packaging specification The SDD specification cites several normative and non-normative references of other standards, including IANA Character Sets, IETF UUID, ISO 639.2, ISO 3166, IETF RFC 2119, IETF RFC 3066, W3C XML Schema, Bureau International des Poids et Mesures, W3C DSIG, and DMTF CIM. Use and relationships of these other standards is described in the SDD specification. Statements of use (viz., a statement from an organizational member that it is successfully using or implementing the specification) were received from CA, Inc., IBM Corporation, and SAS Corporation.

The Limited Lifetime Ubiquitous Protocol (LLUP) Specification
M. David Peterson, O'Reilly Blogs

M. David Peterson, frequent contributor to the O'Reilly Blogs, recently reported: "I've been working on an open messaging protocol specification for the last five or so years [LLUP] which, minus a few minor details that are still being discussed, for all intents and purposes is both feature and functionality complete and simply needs to start the official standardization process... According to the "Limited Lifetime Ubiquitous Protocol (LLUP) Specification Development Project" description: "LLUP is a decentralized messaging protocol which facilitates the ability to broadcast notifications of the existence of time sensitive content related to a given subject matter, addressing this message to any person, place, or thing (potentially) without an immediate understanding ahead of time who the person, place, or thing might represent or apply to directly... LLUP loosely stands for the Limited Lifetime Ubiquitous Protocol and, not by chance, is PULL spelled backwards. This specific acronym was chosen to not only represent the key areas of the specification but to also suggest a PUSH/PULL approach to message dissemination and consumption, where the reversed PULL can also be viewed as 'the other side of push'... At the heart of the LLUP specification is the term BLIP. The BLIP, often referred to as a BLIP message, is a piece of content, declared in a standard way, which acts as a meta-data enriched pointer to the URI of the related content. Similar to a blip on a radar screen, a BLIP message represents a single flash of information which is only seen by those paying attention to a specific channel during the period of time the BLIP is in scope. In the same way a blip on a radar screen represents a virtual pointer to an external physical object, a BLIP message represents a virtual pointer to the external data source where extended information can be found. In addition to an optional short summary, a BLIP message must include four primary pieces of information: (1) A URI Reference: a pointer to the content that the BLIP describes. (2) A Message Lifetime: a start DateTime and expiration DateTime which together represent a lifetime in which the message and related content is deemed relevant by the contents creator. (3) Relevancy of Content: category(s) that are a part of defined or undefined vocabulary, and a UriSignature or signatures of a person, place, or thing the message is targeted towards. (4) A Digital Signature: a means of signing the message for reasons of verification of the original sender... While XML is the primary reference format of the LLUP specification, there is no requirement that a BLIP message must be encoded in the specified XML format. It is up to each service provider to choose which serialization formats they will human readable one-to-one mapping to the LLUP RelaxNG reference schema..." An example uses the Atom syndication format as the body of a BLIP message.

FXStruts: Developing Flex-Friendly Struts Application
Moxie Zhang, InfoQueue

Struts is a Java framework based on standard Java technologies, such as Java Servlet, JavaBean, ResourceBundles and XML. Java developers have been enjoying Struts as a solid server side framework for many years. Recently, a technical evangelist for Adobe Systems, Anirudh Sasikumar, developed a new solution by integrating Flex as Struts' front end. Sasikumar calls it FxStruts. According to Sasikumar: "FxStruts is a free open source library that provides the same functionality as 'bean:write' except that the output is in AMF or XML format. Simply point it to any plain Java object and you get Flex friendly AMF or XML output with ActionErrors and transaction token support." Saikumark demonstrates FxStruts with a Struts MailReader application that has been modified to have a Flex user interface (UI) without any changes to the Action classes. The only changes made were the addition of new JSPs and the mappings in 'struts-config.xml'. For people interested in FxStruts, it is hosted on Google Code and has two pieces: the taglib piece licensed under the ASL 2.0 and the AMF / XML serialization part1 licensed under the LGPL 3.0. The Flex component, HTTPAMFService, is licensed under the MPL 1.1. The Flex version of the struts mailreader application (WAR) is available at Google Code along with a walking tour, highlighting the steps involved in developing a full-fledged Flex application on top of Struts. Documentation on installation and how to migrate an existing Struts application to Flex is also available.

See also: Apache Struts


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

Headlines

Sponsors