Cover Pages: XML Daily Newslink: Monday, 22 October 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:
SAP AG http://www.sap.com

Headlines

CSS Mobile Profile 2.0
SIP Interface to VoiceXML Media Services
SOA Made Fast and Easy
Roadmap for Accessible Rich Internet Applications (WAI-ARIA)
Open Document Format v1.1 Accessibility Guidelines Version 1.0
OASIS EDXL Hospital AVailability Exchange (HAVE) Version 1.0
The Future of File Systems: Jeff Bonwick and Bill Moore Explain ZFS

CSS Mobile Profile 2.0
Svante Schubert (ed), W3C Technical Report

Members of the W3C CSS Working Group have released a Last Call Working Draft for "CSS Mobile Profile 2.0," updating the previous draft of 2006-12-08. Comments are welcome through 15-November-2007. This subset of Cascading Style Sheets (CSS) 2.1 is a baseline for implementations of CSS on constrained devices like mobile phones, written with WICD Mobile 1.0 to ensure interoperability and for alignment with OMA's Wireless CSS Specification 1.1. The specification's 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. Since the goal of the specification is to define a baseline interoperability level, user agents MAY accept CSS documents conforming to CSS 2.1 or subsequent revisions of the CSS family of Recommendations. Document sections 3 (Selectors), 4 (At-rules), and 5 (Properties) clarify features that are required or optional for conformance.

SIP Interface to VoiceXML Media Services
Dave Burke and Mark Scott (eds), IETF Internet Draft

Members of the IETF Media Server Control (MEDIACTRL) Working Group have released an initial Internet Draft for "SIP Interface to VoiceXML Media Services." Commonly, application servers control media servers use this protocol for pure VoiceXML processing capabilities. This protocol is an adjunct to the full MEDIACTRL protocol and packages mechanism. VoiceXML 2.x is a World Wide Web Consortium (W3C) standard for creating audio and video dialogs that feature synthesized speech, digitized audio, recognition of spoken and DTMF key input, recording of audio and video, telephony, and mixed initiative conversations. VoiceXML allows Web-based development and content delivery paradigms to be used with interactive video and voice response applications. The interface described here leverages a mechanism for identifying dialog media services first described in RFC 4240. The interface has been updated and extended to support the W3C Recommendation for VoiceXML 2.0 and VoiceXML 2.1. A set of commonly implemented functions and extensions have been specified including VoiceXML dialog preparation, outbound calling, video media support, and transfers. VoiceXML session variable mappings have been defined for SIP with an extensible mechanism for passing application-specific values into the VoiceXML application. Mechanisms for returning data to the Application Server have also been added. Among the use cases: CCXML/VoiceXML. CCXML 1.0 defines language elements that allow for Dialogs to be prepared, started, and terminated; it further allows for data to be returned by the dialog environment, for call transfers to be requested (by the dialog) and responded to by the CCXML application, and for arbitrary eventing between the CCXML application and running dialog application. The interface described in this document can be used by CCXML 1.0 implementations to control VoiceXML Media Servers.

SOA Made Fast and Easy
Julie Bort, Network World

Of the 11,000 largest enterprises worldwide, 95% are engaged in "some type of effort to implement SOA," according to Susan Eustis, president of WinterGreen Research: "Most of these projects have started out as compliance efforts and have been extended to include a dashboard that is used to manage the business. SOA starts out as a small trial initiative before it is expanded." With so much work going on, the hype around SOA has eroded. In its place are more than a few startling truths: When it comes to SOA, the network is everything. Not every project is SOA friendly. An often shockingly expensive initial SOA project will pay for itself repeatedly over time, as other projects reuse the stockpile of services—provided you've made that reuse easy. Perhaps the biggest school-of-hard-knocks lesson is when not to use a services-approach. "SOA is not a means to an end. You need to use it in the context of solving a business problem," says Steven Weiskircher, vice president of IT for audio-electronics merchant Crutchfield, in Charlottesville, Va. Crutchfield began an SOA pilot about two years ago, when it upgraded its mission-critical catalog/call center, e-commerce and retail order-taking applications, which are 90% custom code... When the benefits of reusability are clear-cut, network executives are left in a pickle. How can they make sure those bloated services fly across the network, particularly as they scale horizontally and vertically? Enter the XML appliance, which offloads processing of XML documents from the server to a network device. Web-services standards specify use of XML document headers that provide routing information, just as IP headers do. Such functions are available in Cast Iron Systems' Application Integration suite, Forum Systems' Vantage, Intel's XSLT Accelerator (a software XML accelerator) and IBM's WebSphere DataPower, as well as in Cisco's Application Oriented Networking (AON) line, via technology the company gained in February, when it acquired Reactivity. When a Web services-based SOA is coupled with an XML appliance, routing moves up the stack. The packet becomes the message. The message is part of the workflow that executes the business logic. Most agree and comply with basic, well-proven Web-services standards [for SOA]. These include WS-Security, SOAP and Universal Description, Discovery, and Integration. In addition, the industry has several alphabets' worth of acronyms in the works as standards or accepted widely. These include Java API for XML-based Web Services, Business Process Execution Language, WS-Reliable Messaging, WS-Addressing, SOAP with Attachments, Message Transmission Optimization Mechanism and WS-Policy.

Roadmap for Accessible Rich Internet Applications (WAI-ARIA)
Staff, W3C Announcement

W3C announced that the Protocols and Formats Working Group has published updated Working Drafts of the WAI-ARIA Roadmap, WAI-ARIA Roles, and WAI-ARIA States and Properties. The WAI-ARIA Suite of documents addresses the accessibility to people with disabilities of dynamic Web content built with Ajax and DHTML. WAI-ARIA includes technologies to map controls, Ajax live regions, and events to accessibility APIs, including custom controls used for rich Internet applications. It also describes new navigation techniques to mark common Web structures as menus, primary content, secondary content, banner information and other types of Web structures. Implementation of WAI-ARIA in languages such as HTML 4, HTML 5 and XHTML is in active development. According to a SecuritySpace Technology Penetration Report, more than 55% of all Web sites today contain JavaScript, dramatically affecting the ability for persons with disabilities to access Web content. HTML and other markup does not provide adequate markup to support accessible dynamic content. A number of W3C initiatives are underway to address this problem using a declarative markup approach. This roadmap is designed to create a bridge to fix the interoperability problem with assistive technologies now by incorporating the appropriate meta data in current XHTML markup to support today's accessibility API. It will incorporate some of the advanced accessibility features, originally designed, in technologies like XHTML2. The intent of XHTML 2 is to make the enablement of Web applications and documents easier for authors. This roadmap will create cross-cutting technologies that XHTML authors may incorporate in their markup to describe GUI widgets and document structures to aide assistive technology vendors in providing accessible, usable solutions. The W3C WAI PF working group will work with User Agent manufacturers and assistive technology vendors to ensure a working solution.

Open Document Format v1.1 Accessibility Guidelines Version 1.0
Peter Korn and Rich Schwerdtfeger (eds),

Members of the OASIS Open Document Format for Office Applications (OpenDocument) TC have approved a Committee Draft version of the "Accessibility Guidelines" for public review. "Open Document Format v1.1 Accessibility Guidelines Version 1.0" is a guide for Office Applications that support version 1.1 of the OpenDocument format, to promote and preserve accessible ODF documents. The public review period ends 21-December-2007. From the Overview: "The Open Document Format v1.1 (ODF) is capable of encoding and storing a lot of structural and semantic information. This information is needed by people with disabilities and the tools they use (assistive technologies), to gain access to computers and information. This document provides guidelines for ODF 1.1 implementation. A successful ODF 1.1 implementation will enable users with disabilities to read, create, and edit documents—with full access to all of the meaning and intent—just like a person without any disability. Accessibility is about enabling people with disabilities to participate in substantial life activities that include work and the use of services, products, and information. In the context of ODF documents, this means that people with disabilities should be able to participate fully in the creation, review, and editing process of the documents. A blind person, for example, should be able to work with a document someone else created (by getting a text description of the images used). A person should be able to fill out a form without using hands. A person with poor vision should be able to read through presentation materials easily."

See also: the OASIS OpenDocument TC

OASIS EDXL Hospital AVailability Exchange (HAVE) Version 1.0
Sukumar Dwarkanath (ed), OASIS Public Review Draft

The EDXL Distribution Element (DE) specification describes a standard message distribution framework for data sharing among emergency information systems using the XML-based Emergency Data Exchange Language (EDXL). This format may be used over any data transmission system, including but not limited to the SOAP HTTP binding. EDXL-HAVE specifies an EDXL-based XML document format that allows the communication of the status of a hospital, its services, and its resources. These include bed capacity and availability, emergency department status, available service coverage, and the status of a hospital's facility and operations. This format may be used over any data transmission system, including but not limited to the SOAP HTTP binding. In a disaster or emergency situation, there is a need for hospitals to be able to communicate with each other, and with other members of the emergency response community. The ability to exchange data in regard to hospitals' bed availability, status, services, and capacity enables both hospitals and other emergency agencies to respond to emergencies and disaster situations with greater efficiency and speed. In particular, it will allow emergency dispatchers and managers to make sound logistics decisions—where to route victims, which hospitals have the ability to provide the needed service. Many hospitals have expressed the need for, and indeed are currently using, commercial or self-developed information technology that allows them to publish this information to other hospitals in a region, as well as EOCs, 9-1-1 centers, and EMS responders via a Web-based tool. Systems that are available today do not record or present data in a standardized format, creating a serious barrier to data sharing between hospitals and emergency response groups. Without data standards, parties of various kinds are unable to view data from hospitals in a state or region that use a different system—unless a specialized interface is developed.

The Future of File Systems: Jeff Bonwick and Bill Moore Explain ZFS
David Brown, ACM Queue

In this interview, ACM Queue speaks with two Sun engineers who are bringing file systems into the 21st century. Jeff Bonwick, CTO for storage at Sun, led development of the ZFS file system, which is now part of Solaris. Bonwick and his co-lead, Sun Distinguished Engineer Bill Moore, developed ZFS to address many of the problems they saw with current file systems, such as data integrity, scalability, and administration. Bonwick and Moore explain what makes ZFS such a big leap forward. "One of the design principles we set for ZFS was: never, ever trust the underlying hardware. As soon as an application generates data, we generate a checksum for the data while we're still in the same fault domain where the application generated the data, running on the same CPU and the same memory subsystem. Then we store the data and the checksum separately on disk so that a single failure cannot take them both out. When we read the data back, we validate it against that checksum and see if it's indeed what we think we wrote out before. If it's not, we employ all sorts of recovery mechanisms. Because of that, we can, on very cheap hardware, provide more reliable storage than you could get with the most reliable external storage. It doesn't matter how perfect your storage is, if the data gets corrupted in flight -- and we've actually seen many customer cases where this happens—then nothing you can do can recover from that. With ZFS, on the other hand, we can actually authenticate that we got the right answer back and, if not, enact a bunch of recovery scenarios. That's data integrity. Another design goal we had was to simplify storage management. When you 're thinking about petabytes of data and hundreds, maybe even thousands of disk drives, you're talking about something that no human would ever willingly take care of. ZFS is composed of several layers, architecturally, but the core of the whole thing is a transactional object store. The bulk of ZFS, the bulk of the code, is providing a transactional store of objects. You can have up to 264 objects, each 264 bytes in size, and you can perform arbitrary atomic transactions on those objects. Moreover, a storage pool can have up to 264 sets of these objects, each of which is a logically independent file system. Given this foundation, a lot of the heavy lifting of writing a Posix file system is already done for you..."

See also: 'What is ZFS?'


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

Headlines

Sponsors