The Cover PagesThe OASIS Cover Pages: The Online Resource for Markup Language Technologies
SEARCH | ABOUT | INDEX | NEWS | CORE STANDARDS | TECHNOLOGY REPORTS | EVENTS | LIBRARY
SEARCH
Advanced Search
ABOUT
Site Map
CP RSS Channel
Contact Us
Sponsoring CP
About Our Sponsors

NEWS
Cover Stories
Articles & Papers
Press Releases

CORE STANDARDS
XML
SGML
Schemas
XSL/XSLT/XPath
XLink
XML Query
CSS
SVG

TECHNOLOGY REPORTS
XML Applications
General Apps
Government Apps
Academic Apps

EVENTS
LIBRARY
Introductions
FAQs
Bibliography
Technology and Society
Semantics
Tech Topics
Software
Related Standards
Historic
Last modified: November 15, 2007
XML Daily Newslink. Thursday, 15 November 2007

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:
EDS http://www.eds.com



Manakin: A New Face for DSpace
Scott Phillips, Cody Green, et al., D-Lib Magazine

Manakin is an abstract framework for building repository interfaces that currently provides an implementation of the DSpace digital repository system. The Manakin framework introduces three unique concepts: the DRI schema, Aspects, and Themes. These are the basic components a Manakin developer will use in creating new functionality for a repository or modifying the repository's look-and-feel. Manakin is built on the Apache Cocoon web development framework, which uses an XML-based pipeline architecture. The pipelined architecture means that an individual page is generated through the combination of many components arranged together along a "pipeline", each feeding into another until the final page is produced. Using this technique, web sites are built through the arrangement of these pipeline components, an approach that is sometimes referred to as a 'Lego-like'. Manakin builds upon these basic Cocoon concepts to create the DRI schema, aspects, and themes. The Digital Repository Interface (DRI) is an XML schema that describes an abstract representation of a repository page. Since repositories fundamentally interact with artifacts and their metadata, the DRI schema must be able to both encode structural concepts and natively represent metadata in various forms. The structural portions of the schema are derived from the Text Encoding Initiative (TEI) schema for its simplicity and expressiveness. The metadata portions of DRI utilize the METS schema for packaging and encoding relationships between an item's components. The descriptive metadata contained within the METS document can be in any one of numerous formats. At the present time Manakin supports DIM (DSpace Intermediate Metadata Format), the XML-based Metadata Object Description Schema (MODS), and qualified or simple Dublin Core. In the future more advanced or content-specific formats might also be supported.

See also: the Apache Cocoon Project


W3C mobileOK Checker: Automatic Verification of mobileOK Content
Staff, W3C Announcement

W3C has announced the W3C mobileOK Checker (alpha) as a new means for people to create and find mobile friendly content. W3C invites Web authors to run the alpha release of the W3C mobileOK checker and make their content work on a broad range of mobile devices. The mobileOK Checker runs tests defined in the "W3C mobileOK Basic Tests 1.0" specification, which has recently been advanced to the status of Candidate Recommendation. The tests themselves are based upon W3C's Mobile Web Best Practices 1.0, published as part of W3C's Mobile Web Initiative. The Best Practices describes how to reduce the cost of authoring and to improve the mobile browsing experience. Any tool that implements the Basic Tests can verify automatically whether content is mobile friendly. The "mobileOK Basic" specification defines a scheme for assessing whether Web resources (Web content) can be delivered in a manner that is conformant with Mobile Web Best Practices to a simple and largely hypothetical mobile user agent, the Default Delivery Context. This document describes W3C mobileOK Basic tests for delivered content, and describes how to emulate the DDC when requesting that content. mobileOK Basic is the lesser of two levels of claim, the greater level being mobileOK Pro, described separately. Claims to be W3C mobileOK Basic conformant are represented using Description Resources (POWDER) also described separately. The intention of mobileOK is to help catalyze development of Web content that provides a functional user experience in a mobile context.

See also: the W3C mobileOK Basic Tests 1.0 CR


Mobile AJAX: Frequently Asked Questions
Ajit Jaokar, SYS-CON Media

Mobile AJAX is the extension of AJAX principles to the mobile environment, which includes other constrained devices such as gaming consoles or set-top boxes featuring Web browsers. While technologically the same thing, Mobile AJAX is looked at as a special case of AJAX, as it deals with problems specific to the mobile space including the areas of constrained devices and constrained Web browsers in general. AJAX itself is a browser technology that involves the use of existing Web standards and technologies (XML/XHTML, DOM, CSS, JavaScript, XHR - XMLHttpRequest) to create more responsive Web applications that reduce bandwidth usage by avoiding full page refreshes and providing a more "desktop application-like" user experience. At a minimum, the requirements for Mobile AJAX include: (1) JavaScript support; (2) XMLHttpRequest object or equivalent ActiveX (for IE only); (3) DOM manipulation functions or innerHTML support—to display request results. On the one hand, Mobile AJAX will be transparent to the end user. For instance, all Nokia devices supporting the S60 and Opera browsers support AJAX - but that makes little difference to the end user. On the other hand, Widgets are enabled by Mobile AJAX. Thus, the visual (end user) manifestation of Mobile AJAX may be in the form of Widgets or rich browser-based applications such as we see on new Nokia phones or Opera browsers.


Open Source and Messaging's Future
Alice Lipowicz, Washington Technology

This article presents a conversation with Art Botterell, national expert in warning systems and former FEMA official. When Art Botterell was helping develop public warning systems in California a decade ago, the state already had sirens and broadcast TV messaging. So he and others began adding telephones, weather radios and computers. He saw an urgent need for a common messaging format that would be freely available to all vendors and users. He helped organize a grass-roots effort in 2000 and 2001 for more than 100 computer programming volunteers active in emergency management to create an Extensible Markup Language format for public warning messages. It was named the Common Alerting Protocol (CAP). Botterell: "What we found was that if you start with the technology, you have to devise the message to fit the technology. With CAP, we started with the social science and the need for public warnings. We defined the characteristics of an effective warning system and messaging system and developed it from there to fit multiple devices and formats. An effective message has to hit you two to three times, so it has to be multimodal. Most people will not evacuate based on a solitary message... You can prepare for a disaster with the National Incident Management System and the National Response Framework, but the reality is always messy and unpredictable. There always will be chaos and people who have not worked together before. You need something like a Google search engine available to help officials quickly identify all assets available for response, regardless of the source. That is the next frontier. We need help with navigation, indexing and discussing. We constantly need innovation to solve the really deep and interesting problems. If we allow the existing set of contractors to define the space, they will define it with solutions that they already have. I hope that the CAP can serve as an example of an alternative way of doing things from the grass-roots. Open-source computing is a vital partner for developing solutions.

See also: CAP references


Additional XML Security Uniform Resource Identifiers (URIs)
Donald E. Eastlake 3rd (ed), IETF Internet Draft

This document expands and updates the list of URIs intended for use with XML Digital Signatures, Encryption, Canonnicalization, and Key Management specified in RFC 4051 (April 2005). These URIs identify algorithms and types of information. XML Digital Signatures, Canonicalization, and Encryption have been standardized by the W3C and by the joint IETF/W3C XMLDSIG working group. All of these are now W3C Recommendations and IETF Informational or Standards Track documents. All of these standards and recommendations use URIs (RFC 3986) to identify algorithms and keying information types. This document is a convenient reference list of URIs and descriptions for algorithms in which there is substantial interest but which can not or have not been included in the main documents for some reason. Note in particular that raising XML digital signature to Draft Standard in the IETF required remove of any algorithms for which there was not demonstrated interoperability from the main standards document. This required removal of the Minimal Canonicalization algorithm, in which there appears to be continued interest, to be dropped from the standards track specification. It was included in RFC 4051 and is included here.

See also: Additional XML Security URIs


Web Services Hints and Tips: JAX-RPC versus JAX-WS, Part 5
Russell Butek and Nicholas Gallardo, IBM developerWorks

Java API for XML-based RPC (JAX-RPC) supports the SOAP with Attachments (Sw/A) specification, while Java API for XML Web Services (JAX-WS) supports Sw/A along with the new Message Transmission Optimization Mechanism (MTOM) specification. The attachment model for JAX-RPC is Sw/A. Since JAX-RPC was written, a new attachment model has come onto the scene: MTOM. JAX-WS provides Sw/A support just as JAX-RPC does, but adds support for MTOM. JAX-WS supports MTOM via the Java Architecture for XML Binding (JAXB) specification, which includes APIs for marshalling and unmarshalling both Sw/A and MTOM attachments. In this article the author examines both models through examples. This tip compares only the WSDLs and the Java programming models; comparing the wire-level messages is left as an exercise to the reader. JAX-RPC supports the Sw/A model. JAX-WS supports Sw/A as well, but it has also stepped up to the new MTOM model. MTOM is an improvement upon Sw/A in a number of ways: (1) Everything necessary to create a Java interface is now available in the WSDL interface; (2) MTOM is usable in a document/literal wrapped WSDL; (3) MTOM allows optimization to attachments, but it doesn't force attachments like Sw/A does.


IBM's Hosted Symphony: Will Anyone Listen?
Sean Gallagher, InfoWorld Blog

IBM appears to be getting ready to offer its Lotus Symphony suite as a hosted application, competing directly with Google Apps and Microsoft's Office Live. Does IBM's entry into the on-demand desktop application space signal trouble for Office? Microsoft's Office Live strategy is still primarily focused on small business, for groups of 10 or fewer users. It's not an enterprise-changing play. Microsoft's enterprise applications on demand are more in the form of services, not desktop tools—Exchange and SharePoint, for example. IBM started giving away Symphony for free in September, following a similar path to Sun's with StarOffice, though OpenOffice.org is admittedly not the same thing as Sun's commercial release. The chances, however, of a free Symphony desktop suite displacing Office in the corporate world are close to nil. And while a hosted version might be interesting to organizations still using Lotus Notes, it's doubtful that it would upset anyone's applecart, aside from Google's efforts... In a corporate environment, there's concern over capturing workflow for compliance and the security of an Internet-based tool—which can be solved by hosting internally. But if you're hosting it internally, you're really just solving one problem—software distribution—and trading it for another set. Now, you've got to manage the servers, deal with network bandwidth demands as XML traffic goes up, and shift your storage needs from network shared drives to server-side storage. That's not to say there isn't anything interesting about hosted desktop applications. Hundreds of organizations are already using hosted applications—through desktop virtualization via Citrix and Terminal Server.


Introduction to Amazon S3 with Java and REST
Eric Heuveneers, O'Reilly ONJava.com

Amazon Simple Store Service (S3) is a service from Amazon that allows you to store files into reliable remote storage for a very competitive price; it is becoming very popular. S3 is used by companies to store photos and videos of their customers, back up their own data, and more. S3 provides both SOAP and REST APIs; this article focuses on using the S3 REST API with the Java programming language. It detailes how to implement bucket creation in Java and how to deal with S3 security principles. It shows that HTTP and XML skills are needed when developing with S3 REST API. Some S3 operations could be improved, especially for upload, but overall Amazon S3 rocks... S3 handles objects and buckets. An object matches to a stored file. Each object has an identifier, an owner, and permissions. Objects are stored in a bucket. A bucket has a unique name that must be compliant with internet domain naming rules. Once you have an AWS (Amazon Web Services) account, you can create up to 100 buckets associated with that account. An object is addressed by a URL, such as "http://s3.amazonaws.com/bucketname/objectid". The object identifier is a filename or filename with relative path (e.g., myalbum/august/photo21.jpg). With this naming scheme, S3 storage can appear as a regular file system with folders and subfolders. Notice that the bucket name can also be the hostname in the URL. S3 REST resources are secure. This is important not just for your own purposes, but also because customers are billed depending on how their S3 buckets and objects are used. An AWSSecretKey is assigned to each AWS customer, and this key is identified by an AWSAccessKeyID. The key must be kept secret and will be used to digitally sign REST requests. The signing algorithm is HMAC/SHA1 (Hashing for Message Authentication with SHA1).


Sponsors

XML Daily Newslink and Cover Pages are sponsored by:

BEA Systems, Inc.http://www.bea.com
EDShttp://www.eds.com
IBM Corporationhttp://www.ibm.com
Primetonhttp://www.primeton.com
SAP AGhttp://www.sap.com
Sun Microsystems, Inc.http://sun.com

XML Daily Newslink: http://xml.coverpages.org/newsletter.html
Newsletter Archive: http://xml.coverpages.org/newsletterArchive.html
Newsletter subscribe: newsletter-subscribe@xml.coverpages.org
Newsletter unsubscribe: newsletter-unsubscribe@xml.coverpages.org
Newsletter help: newsletter-help@xml.coverpages.org
Cover Pages: http://xml.coverpages.org/



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

Sponsored By

IBM Corporation
ISIS Papyrus
Microsoft Corporation
Oracle Corporation

Primeton

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

 Newsletter Subscription
 Newsletter Archives
Globe Image

Document URI: http://xml.coverpages.org/newsletter/news2007-11-15.html  —  Legal stuff
Robin Cover, Editor: robin@oasis-open.org