This issue of XML Daily Newslink is sponsored by:
SAP AG http://www.sap.com
- 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.
See also: the W3C Style Activity Statement
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.
See also: the IETF MEDIACTRL) WG Charter
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
See also: the WAI-ARIA Roadmap document
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.
See also: the OASIS Emergency Management TC
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?'
XML Daily Newslink and Cover Pages are sponsored by:
|BEA Systems, Inc.||http://www.bea.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: firstname.lastname@example.org
Newsletter unsubscribe: email@example.com
Newsletter help: firstname.lastname@example.org
Cover Pages: http://xml.coverpages.org/