Cover Pages: XML Daily Newslink: Monday, 22 September 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:
Oracle Corporation http://www.oracle.com

Headlines

W3C Proposed Recommendation: Device Description Repository Simple API
A Generic, Reusable Solution for Marshalling Java Objects to/from XML
Using POST to add to Web Distributed Authoring and Versioning (WebDAV) Collections
Experience of Implementing NETCONF over SOAP
RESTful Grails: Build a Resource-Oriented Architecture
Information Cards Are Awesome, but Are Identifying Parties Really Ready To Do This Right?

Cover Pages

Open Web Foundation Formed to Support Community Specification Development

W3C Proposed Recommendation: Device Description Repository Simple API
Jo Rabin, Jose Manuel Cantera (et al., eds), W3C Technical Report

Members of the W3C Mobile Web Initiative Device Description Working Group have published the "Device Description Repository Simple API" specification as a W3C Proposed Recommendation. It reflects changes made as a result of comments received during the Last Call period. A "Disposition of Comments" report is available, together with a DDR Simple API Implementation Report. Given the implementation experience contained in the implementation report, this Technical Report has gone from Last Call to Proposed Recommendation without a Candidate Recommendation stage. Comments are welcome through 31-October-2008. Web content delivered to mobile devices usually benefits from being tailored to take into account a range of factors such as screen size, markup language support and image format support. Such information is stored in "Device Description Repositories" (DDRs). This document describes a simple API for access to DDRs, in order to ease and promote the development of Web content that adapts to its Delivery Context. The need for Device Descriptions (information about the Properties of various Aspects of the Delivery Context) is not confined to the mobile Delivery Context. It is common practice for Web sites to detect the type of user agent ("browser sniffing") to determine possibly small but important differences between various desktop Web browsers and adapt content to accommodate those differences. In the desktop Delivery Context, the number of different Properties that affect the usability of the resulting content is limited, when compared with the number of different Properties of the mobile Delivery Context that affect usability of content. Examples of such Properties include screen dimensions, input methods, memory and CPU constraints. There are also differences between mobile Web browsers including markup languages supported and image formats supported. Historically, it has been difficult or impossible to upgrade Web browser software on mobile devices or to add support for features not present in the Web browser originally shipped with the device. This leads to a very wide variation not only of hardware related features but also of features determined by software and firmware. Although the need for content adaptation is a general requirement of the Web as a whole, the need for a more systematic approach is seen as being most urgent in the mobile Delivery Context. As a result, Device Description Repositories (DDRs) have become essential components of development of content targeted at the mobile Delivery Context. A number of proprietary implementations exist, each with its own API and method of describing the Properties of the Delivery Context.

A Generic, Reusable Solution for Marshalling Java Objects to/from XML
Michael Pilone, DevX.com

The callback approach to mapping from Java objects to XML solves many of the problems found with existing solutions. XML is now at the backbone of most client/server applications, from XHTML to SOAP web services to RESTful services, preferences, persistence, and configuration. However, even with the advent of XML, mapping from objects such as Java class instances to XML is not always trivial. In particular, using a "contract first" approach that defines an XML schema, namespaces, and XML data types can be arduous. Object-to-XML mapping (OXM) libraries such as JAXB, XMLBeans, and XStream have made OXM easier, and they've helped to define APIs that serve as the foundation of serialization for tools such as Spring Web Services (Spring-WS). These libraries work by generating classes or using Java annotations to map the objects to a defined XML schema automatically. So the application developer simply instantiates an object, populates the data, and tells the library to marshal the object to well-formed XML. The process then works in reverse when the application unmarshals the XML back into objects by feeding the XML into the library. A common architectural pattern for applications using OXM involves defining a generic marshaller and unmarshaller interface. This approach hides the actual marshalling technology behind the interface to enable multiple implementations, easier mock testing, consistent exception handling, and future flexibility. However, these interfaces, combined with the hierarchical nature of XML, require that the entire object to be marshalled live in memory, which becomes a major hindrance when the objects grow too large. For example, how do you marshal a web server access log that may contain tens of thousands of requests, or how do you marshal a security audit log for multiple users on the system simultaneously without exhausting memory? A better solution (albeit with a few limitations) is the callback approach, which solves many of the problems found with existing solutions for large object XML serialization. Using a callback-based API allows an application to "stream" objects in and out of XML while still gaining all the benefits of OXM, such as namespace handling, element-to-field mappings, and data type conversions. This article explains how the callback approach solves problems such as direct low-level XML handling and custom OXM marshallers.

Using POST to add to Web Distributed Authoring and Versioning (WebDAV) Collections
Julian F. Reschke (ed), IETF Internet Draft

The Hypertext Transfer Protocol (HTTP) Extensions for the Web Distributed Authoring and Versioning (WebDAV) do not define the behavior for the "POST" method when applied to collections, as the base specification (HTTP) leaves implementers lots of freedom for the semantics of "POST". This has lead to a situation where many WebDAV servers do not implement POST for collections at all, although it is well suited to be used for the purpose of adding new members to a collection, where the server remains in control of the newly assigned URL. As a matter of fact, the Atom Publishing Protocol (AtomPub) uses POST exactly for that purpose. On the other hand, WebDAV-based protocols such as the Calendar Extensions to WebDAV (CalDAV) frequently require clients to pick a unique URL, although the server could easily perform that task. This specification defines a discovery mechanism through which servers can advertise support for POST requests with the aforementioned "add collection member" semantics. Due to the reasons described in Section 1, clients can not rely on a specific server behavior when POST is applied to a collection. This problem is addressed by this specification by allowing servers to advertise a URI that has the desired "add member" semantics. Note that servers that already use POST for a different purpose can just expose a different URI for that purpose. Other servers can just advertise the collection's own URI, thus avoiding to mint another URI for a limited purpose. The "Add-Member" URI of a WebDAV collection is a URI that will accept HTTP POST requests, and will interpret these as requests to store the enclosed entity as a new internal member of the collection. The URI of the newly created resource is returned in the HTTP Location response header. There may be cases in which it is more efficient to expose the Add- Member URI in HTTP headers or in (X)HTML content. For this use case, this specification defines a new link relation with the name: 'http://purl.org/NET/webdav/post#add-member'... In the AtomPub protocol, clients can use the entity header "Slug" to suggest parts of the URI to be created. Note that servers are free to ignore this suggestion, or to use whatever algorithm that makes sense to generate the new URI. The same applies to the extension defined here: clients can use the "Slug" header as by its definition of a generic HTTP header. Servers should process it exactly the way defined by AtomPub.

See also: Atom references

Experience of Implementing NETCONF over SOAP
Iijima Tomoyuki, Yoshifumi Atarashi (et al., eds), IETF Internet Draft

The Internet Engineering Steering Group (IESG) has announced the approval of "Experience of Implementing NETCONF over SOAP" as an Informational RFC. This document describes how the authors developed a SOAP (Simple Object Access Protocol)-based NETCONF client and server. In the case that SOAP is used as a transport protocol for NETCONF, various kinds of development tools are available. By making full use of these tools, developers can significantly reduce their workload. The authors developed an NMS (Network Management System) and network equipment that can deal with NETCONF messages sent over SOAP. This document aims to provide NETCONF development guidelines gained from the experience of implementing a SOAP-based NETCONF client and server. Several SOAP implementations appropriate for use in an NMS are available today. Apache Axis is one such widely used implementation. Axis works as a SOAP implementation and an NMS-development tool. For instance, WSDL2Java, one of Axis' tools, generates Java-class files from a WSDL file. Another tool called Java2WSDL does the opposite: it generates a WSDL file from Java-class files. Consequently, various benefits can be obtained if Axis is introduced as a SOAP implementation. To develop a NETCONF application that is capable of various functions such as releasing log messages, Java-class files generated by the Axis tool may be extended by adding more functions. By utilizing these Java libraries, engineers can easily develop NETCONF applications. This document is an individual submission. Presentations were made in the NETCONF Working Group, the NETCONF WG chairs reviewed the document but no formal review was undertaken by the WG. The document is based upon the implementation experienced gathered by the authors in implementing RFC 4741 and RFC 4743. The document was reviewed by Dan Romascanu as Area Director, by Mehmet Ersue and Bert Wijnen, co-chairs of the NETCONF WG, and by Stefan Santesson for the security directorate. This document is an indivudual submission and Dan Romascanu is the shepherding AD.

RESTful Grails: Build a Resource-Oriented Architecture
Scott Davis, IBM developerWorks

We live in the era of mashups. Creating Web pages that give users the information they want is a good start, but offering a source of raw data that other Web developers can easily mix in with their own applications is better. In this installment of 'Mastering Grails', Scott Davis introduces various ways to get Grails to produce XML instead of the usual HTML. "I would normally describe this as setting up Web services for your Grails application, but the term is loaded with hidden meanings these days. Many people associate Web services with SOAP and a full-blown service-oriented architecture (SOA). Two plug-ins for Grails allow you to expose a SOAP interface to your application if you choose that route. But rather than deal with a specific implementation such as SOAP, I'll show you how to return Plain Old XML (POX) using an interface based on Representational State Transfer (REST). When it comes to RESTful Web services, it's as important to understand the why as much as the how. Roy Fielding's doctoral dissertation (the source of the REST acronym) outlines two approaches to Web services: one that's service-oriented and another that's resource-oriented... Grails is a modern Web development framework that mixes familiar Java technologies like Spring and Hibernate with contemporary practices like convention over configuration. Written in Groovy, Grails give you seamless integration with your legacy Java code while adding the flexibility and dynamism of a scripting language... The article should help you understand the difference between an SOA and an ROA. You should also recognize that not all RESTful Web services are the same. Some of them are GETful—using an HTTP GET request for RPC-like method calls. Others are truly resource-oriented, where the URI is the key accessing the resource, and the standard HTTP GET, POST, PUT, and DELETE methods give you full CRUD capabilities. Whether you prefer the GETful or RESTful approach, Grails offers robust support for outputting XML and effortlessly ingesting it back.

Information Cards Are Awesome, but Are Identifying Parties Really Ready To Do This Right?
Sara Peters, InformationWeek

Perhaps the greatest thing about information cards is that they might finally free us from the purpose-defeating practice of using Social Security numbers as a nigh-universal identifier. But it won't work unless the Identifying Parties find a way to balance security with portability, and can smartly manage distribution, expiration and destruction. An SSN is worse than a password, even worse than useless as an identifier. First of all, it's easy to brute force: always nine characters (unless it's truncated, and then you may only need four) and only 10 possibilities for each character. Second of all, unlike a fingerprint, (or a driver's license number, or a bank account number, or really just about any piece of personal data) there is no way to verify that the Social Security Number you've provided is actually yours. Why is it impossible to verify? Because the Social Security Administration will not tell anyone what SSN belongs to whom, apparently because it would jeopardize individuals' privacy and the security of the numbers... With an information card, the information itself isn't very important—in some instances it might actually be entirely unnecessary. The important part is that the information has been verified by a trusted identifying party. In this way it's better than the hard copy IDs in your wallet. The relying party gets the information they want, without forcing the user to toss around personal data willy-nilly. However the trouble with information cards is that they're simply digital files, which means they can be copied by someone other than the identifying party, stored on several devices and transmitted over insecure channels. InfoCards, like encryption keys must be both transmitted and stored securely. If an attacker gets hold of those Infocards then the identifying (verifying) party will, unknowingly, attest to the fraudulent claims of the attacker without the attacker needing to know a single piece of the victim's personal information. The infocards must be portable—so it's likely they'll be stored on a smartcard or an encrypted USB stick. Yet they must also be secure—so that portable device containing the issued information card should be obtained in-person, directly from the identifying party. It sounds like all this calls for interoperable standards. Hopefully the collaborative work being done by Microsoft and the Information Card Foundation will help us move in that direction.

Selected from the Cover Pages, by Robin Cover

Open Web Foundation Formed to Support Community Specification Development

The formation of the Open Web Foundation (OWF) was announced on July 24, 2008 at the OSCON 2008 Conference. OWF is "applying the open source model of seeing a common pain point and trying to patch the system by creating an 'organizational library' that makes it easier to go through a collaborative specification process and come out of it with clean IPR, leading to faster implementation and adoption." Speaking on behalf of thirty-some individual collaborators and with promised support from several companies (BBC, Facebook, Google, MySpace, O'Reilly, Plaxo, Six Apart, SourceForge, Vidoop, Yahoo!), David Recordon of Six Apart presented the rationale and key points of focus for the new foundation: Incubation: creating new open specifications for the web; Licensing: or really no licensing, use of non-assertion agreements; Copyright: Creative Commons for each specification; Community: diverse collaboration of individuals and companies held accountable to support the Open Web. According to the OWF web site: "The Open Web Foundation is an independent non-profit dedicated to the development and protection of open, non-proprietary specifications for web technologies. It is an attempt to create a home for community-driven specifications. Following the open source model similar to the Apache Software Foundation, the foundation is aimed at building a lightweight framework to help communities deal with the legal requirements necessary to create successful and widely adopted specification. The foundation is trying to break the trend of creating separate foundations for each specification, coming out of the realization that we could come together and generalize our efforts... The Open Web Foundation is made up of individuals who believe that the open web is built on technologies that are created in the open by a diversity of contributors, and which free to be used and improved upon without restriction." David Recordon's inaugural presentation on OWF referenced three major open specifications which have gained popularity the past year: OpenID, OAuth, OpenSocial. "They are quite similar: (1) They represent community efforts that include individuals and companies; (2) They are occurring outside of formal standards bodies: people are just working on mailing lists; (3) They use Open Source reference implementations in many languages; (4) They are enjoying major adoption at an increasing pace; (5) They are open specifications designed to be freely implementable by anyone.


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

Headlines

Cover Pages

Sponsors