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: February 17, 2010
XML Daily Newslink. Wednesday, 17 February 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

CFP: W3C Workshop on Future Standards for Model-Based User Interfaces
Staff, W3C Announcement

W3C has announced a 'Workshop on Future Standards for Model-Based User Interfaces', to be held May 13-14, 2010 in Rome Italy. The meeting will be hosted by the CNR-ISTI HIIS Laboratory.

W3C invites anyone to attend a workshop "to discuss the challenges and benefits of Model-Based approaches, to hear the main results achieved by the Incubator Group, and to facilitate a discussion about the next steps to be taken in the area of open standards for Model-Based User Interfaces. Workshop participants will collectively help to identify opportunities and challenges for new open standards in the area, particularly concerning the semantics and syntaxes of task, abstract and concrete user interface models. In addition, workshop participants will have the opportunity to discuss the role of model-based approaches in relation to other standards, for instance, XForms, ANSI/CEA-2018 and MDA, and the relationship to work on standards for Web delivery including HTML5 and browser scripting APIs."

Background: "During the last year, the W3C Model-Based UI XG has evaluated research on model-based user interfaces, including end-to-end models that extend beyond a single Web page, and has assessed its potential as a framework for developing context-sensitive Web applications... Web application developers face increasing difficulties due to wide variations in device capabilities, in the details of the standards they support, the need to support assistive technologies for accessibility, the demand for richer user interfaces, the suites of programming languages and libraries, and the need to contain costs and meet challenging schedules during the development and maintenance of applications. Research work on model-based design of context-sensitive user interfaces has sought to address the challenge of reducing the costs for developing and maintaining multi-target user interfaces through a layered architecture that separates out different concerns: (1) application task models, data and meta-data; (2) abstract interface—device and modality independent, e.g. select 1 from n; (3) concrete interface -- device and/or modality dependent, e.g. use of radio buttons; (4) implementation on specific devices with wide variations in hardware and software capbilities—e.g. html+javascript, svg, java, .net or flash...

The workshop should be of relevance to any of the following communities: Model-Based (or Model-Driven) UI technology vendors and developers, including open source projects; companies that own solutions for the development of multi-target, context-sensitive, adaptive User Interfaces; companies seeking to exploit Model-Based Approaches internally; software vendors or open source projects that currently offer XML-based languages for the description of user interfaces targeted to the desktop environment; government organizations seeking to the standardization of UI development; academic researchers with an interest in Model-Based UI Development..."

See also: W3C Workshops

VWRAP: Abstract Type System for the Transmission of Dynamic Structured Data
Meadhbh Hamrick and Mark Lentczner (eds), IETF Internet Draft

An initial -00 version Internet Draft has been published by IETF for VWRAP: Abstract Type System for the Transmission of Dynamic Structured Data, along with five(+) related documents: (1) Virtual World Region Agent Protocol: Client Application Launch Message, (2) VWRAP Trust Model and User Authentication, (3) VWRAP: Introduction and Goals, <4) VWRAP Deployment and Trust Patterns, (5) Virtual World Region Agent Protocol: Foundation. This document "describes the LLIDL interface description language, the related LLSD abstract type system and three serialization formats for LLIDL messages. LLIDL (pronounced 'little') is a language-neutral facility for describing transport independent message flows for RESTful resource access. LLIDL itself is an abstract meta-grammar for producing and recognizing valid request / response messages affecting state change in application layer objects by way of RESTful resource access. It may be used by protocol developers and system deployers to describe the composition of application layer protocol exchanges without adopting transport specific message semantics or programming language specific type semantics...

The type behavior of individual message elements is described by the LLSD abstract type system. Abstract LLIDL messages are concretized using one of three defined LLSD serialization schemes. Serialization / deserialization rules are provided in this document for XML, JSON and Binary schemes. This abstract messaging and type system is intended to be used by other specifications to describe application layer protocol exchanges, independent of implementation language or message transport protocol..."

As presented in Virtual World Region Agent Protocol: Client Application Launch Message, messages in VWRAP message format are intended to be used in conjunction with standard web authentication or authorization technologies such as OpenID or OAuth... OpenID and OAuth traditionally use a HTTP redirect after user or token authentication to begin an authorized session with a web application. The problem in using desktop applications with "web auth" technologies is that desktop applications do not generally have a URL to act as the target of HTTP redirection... This document describes the format of a web resource suitable for signaling the user's web browser to launch a virtual world client application that uses Virtual World Region Agent Protocol (VWRAP) Authentication to establish a session between the client application and network resources implementing the virtual world..."

VWRAP Authentication: "Authentication is the first step in associating a client application with the agent domain (the remote service responsible for agent identity management.) Before a client application may interact with the agent domain or one or more hosts responsible for virtual world simulation, it must authenticate itself by presenting credentials demonstrating its right to control the agent. Authentication is the process of presenting an "Identifier" and an "Authenticator" to the agent domain and receiving a "Seed Capability" providing further access to system resources or an actionable error description. The protocol defines an identifier as an agent or account information, distinct from its related authenticator..."

See also: VWRAP Introduction and Goals

Java EE6 Web Services: JAX-RS 1.1 Provides Annotation Based REST Support
Srini Penchikala, InfoQueue

"JavaEE 6 release includes Java API for RESTful Web Services (JAX-RS) support which provides a POJO based framework to build lightweight web services that conform to the Representational State Transfer (REST) style of software architecture. JAX-RS API, which is part of JSR 311, offers several annotations that can be used to expose Java class methods as web resources. JAX-RS automatically translates between Java types and MIME media types. For example, if you mark a class method with annotation '@Produces (MediaType.TEXT_PLAIN)', JAX-RS would translate the Java type to the 'text/plain' MIME type, which represents plain text, and return content of that type in the HTTP response to the client. Java EE 6 includes the latest release of the technology, JAX-RS 1.1, which is a maintenance release that aligns JAX-RS with new features in Java EE 6. Jersey is the open source Reference Implementation for JAX-RS specification. Jersey 1.1.5 version implements JAX-RS 1.1...

JAX-RS also has other convenient features like parameter-based annotations that can be used to extract information from a request. One of these annotations is @QueryParam, which can be used to extract query parameters from the Query component of a request URL. Other parameter-based annotations are @MatrixParam, which extracts information from URL path segments, @HeaderParam, which extracts information from HTTP headers, and @CookieParam which extracts information from the cookies declared in cookie-related HTTP headers.

The RESTEasy framework from JBoss is another implementation of the JAX-RS specification. Apache's open source services framework CXF will also provide support for JAX-RS 1.1 as part of their version 2.3 release..."

IETF Informational Internet Draft: An IETF Privacy Policy
Alissa Cooper (ed), IETF Internet Draft

A draft IETF Privacy Policy has been released through the IETF Internet Draft publication process. The document proposes language to serve as the IETF's privacy policy. This policy applies to data collected in conjunction with IETF activities and on public IETF-related web sites.

From the Introduction: "In keeping with the goals and objectives of this standards body, the IETF is committed to the highest degree of respect for the privacy of IETF participants and site visitors. This policy applies to data collected in conjunction with IETF activities, whether online or in person, and on public web sites hosted on,,,, and The document is meant to be a strawman proposal for a public-facing privacy policy that any visitor to IETF-related web sites can read and understand. The policies described are a combination of observations about the data the IETF collects, language from the ISOC privacy policy, and examples of good policies from other organizations...

Several privacy policy topics are addressed in the draft: (1) Information that is automatically collected on IETF-related web sites [e.g., Internet Protocol address, browser type and operating system, cookie, URL of referring page, whether you have bookmarked our web site on your web browser, the first/last web page within our site that you visit, bandwidth used, amount of time in session visit, time and date of your site visit]; (2) Information you can choose to share with the IETF; (3) Data disclosure; (4) Data retention; (5) Security Considerations; (6) Changes to the privacy policy; (7) Your privacy questions...

Map and Subset NIEM IEPDs for XML Information Exchange
Priscilla Walmsley, IBM developerWorks

This article, Part 2 in a series, shows how to map a model to NIEM to determine what parts of NIEM an exchange can reuse; it also shows how to create a subset of the NIEM model to include in an IEPD (Information Exchange Package Documentation). Part 1 of this series described the process of creating a UML model of an XML information exchange to be implemented in the National Information Exchange Model (NIEM).

"Conceptually, NIEM is essentially a data model providing the reference vocabulary for consistent and repeatable interagency and inter-domain exchanges of information. The model is represented in a number of forms, including a data dictionary, and a reference schema, and includes the body of concepts and rules that underlie its structure, maintain its consistency, and govern its use. NIEM uses extensible markup language (XML) as its rendering language. XML allows the structure and meaning of data to be defined through simple but carefully defined syntax rules, thereby providing a common framework for information exchange. The models' unique architecture enables data components to be constrained, extended, and augmented as necessary to formulate XML exchange schemas, and XML instance documents defining the information payloads (content) for data exchange. These exchange defining documents are packaged in IEPDs that are re-usable, modifiable and extendable..."

To map a model to NIEM to determine what parts of NIEM you will reuse in your messages, mapping is most commonly done in a spreadsheet, known as a Component Mapping Template (CMT). The CMT is useful for several reasons: (1) It provides a detailed, human-readable definition of your exchange model with places for comments and extra documentation; (2) It makes explicit which parts of the model reuse NIEM components and which are custom to the Information Exchange Package Documentation; (3) It serves as a convenient checklist when you make a subset of the NIEM model..."

See also: the NIEM web site

OpenCMIS joins Apache Chemistry
Florian Mueller, Open Text Blog

"One of the details that distinguish CMIS from other standard efforts is that all major ECM vendors have built CMIS prototypes long before the specification has been ratified. It's not surprising that most of these prototypes are repository interfaces and simple GUI clients. But an enterprise-ready client library was missing. So Open Text, SAP, and Alfresco teamed up in summer 2009 to build an open source CMIS client library for Java. We called it OpenCMIS.

All three companies brought their CMIS experiences to the table. Our first CMIS prototypes go back to spring 2008. We already had experimented with CMIS clients and knew how a client library should look like. And we could also contribute proven code fragments. Meanwhile the low-level client that implements the CMIS bindings has been tested against most of the public CMIS implementations and against some that are not publicly available...

Today OpenCMIS is more than a client library. It also consists of a CMIS server framework and a set of tools. It was time for a bigger community. The OpenCMIS group proposed a contribution to Apache and has been invited to join Apache Chemistry. Finally, the OpenCMIS source code will be added to Apache Chemistry this week. We are really looking forward to this collaboration. Together we can extend and improve our code bases and foster the adoption of CMIS..."

See also: CMIS references

W3C Proposed Recommendation: XML Entity Definitions for Characters
David Carlisle and Patrick Ion (eds), W3C Technical Report

The W3C Math Working Group has published a Proposed Recommendation for the specification XML Entity Definitions for Characters. This document defines several sets of names, so that to each name is assigned a Unicode character or sequence of characters. Each of these sets is expressed as a file of XML entity declarations. It is is a mature document that has been widely reviewed and has been shown to be implementable, so W3C encourages implementation of this specification. The document did not undergo Candidate Recommendation review, because no software is needed to implement the specification other than a standard XML parser... The names are presented in two tables: "Characters Ordered by Entity Name" and "Characters Ordered by Unicode."

Details: "Notation and symbols have proved very important for human communication, especially in scientific documents. Mathematics has grown in part because its notation continually changes toward being succinct and suggestive. There have been many new signs developed for use in mathematical notation, and mathematicians have not held back from making use of many symbols originally introduced elsewhere. The result is that science in general, and particularly mathematics, makes use of a very large collection of symbols. It is difficult to write science fluently if these characters are not available for use. It is difficult to read science if corresponding glyphs are not available for presentation on specific display devices. In the majority of cases it is preferable to store characters directly as Unicode character data or as XML numeric character references.

However, in some environments it is more convenient to use the ASCII input mechanism provided by XML entity references. Many entity names are in common use, and this specification aims to provide standard mappings to Unicode for each of these names. It introduces no names that have not already been used in earlier specifications. Note that these names are short mnemonic names designed for input methods such as XML entity references, not the longer formal names that form part of the Unicode standard...

This document is the result of years of employing entity names on the Web. There were always a few named entities used for special characters in HTML, but a flood of new names came with the symbols of mathematics. This means that this document can be viewed as an extension and final revision of Chapter 6 of the MathML 2.0 W3C Recommendation. Now it presents a completed listing harmonizing the known uses of character entity names throughout the XML world and Unicode. Since there are so many character entity names, and the files specifying them are resources that may be subject to frequent lookup, a template catalog file has also been provided. Users are strongly encouraged to design their implementations so that relevant entity name tables are cached locally, since it is not expected that the listings provided with this specification will need changing for some long time..."

See also: the W3C MathML Activity

Create Text Macros to Add Entities in XML
Chris Herborth, IBM developerWorks

"Many developers use entities in their XHTML for special characters, but in XML you can also define entities to make authoring easier, or to reference the content of external documents. Entities are also useful when you create a Document Type Definition (DTD) and want to reduce its apparent complexity to keep it readable by humans...

Entities are references to data; depending on the kind of entity, the XML parser will either replace the entity reference with the entity's replacement text or the contents of an external document. In this article, you look at several kinds of entities, and learn how they work, and how to take advantage of them in your own XML documents: (1) Character entities; (2) Named entities; (3) External entities; (4) Parameter entities...

XML-based standards like XHTML define a library of useful entities that make it possible to create documents with characters that you can't type directly on standard keyboards. Named entities can act like macros, letting you replace repetitive or difficult text with entity references. While Web browsers don't support external entities, you can use them to create composite documents using other XML applications, which makes it easier to standardize and re-use parts of your documents. Use parameter entities to pull external declarations into your DTD, or to create in-DTD macros to improve readability...

See also: Entity Declarations in XML


XML Daily Newslink and Cover Pages sponsored by:

IBM Corporation
Microsoft Corporation
Oracle Corporation
Sun Microsystems, Inc.

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: