|
XML and Web Services In The News - 27 September 2006
Provided by OASIS |
Edited by Robin Cover
This issue of XML Daily Newslink is sponsored by Innodata Isogen
HEADLINES:
The Relationship Between WS-ReliableMessaging and WS-Polling
Doug Davis, IBM developerWorks
The WS-Reliable Exchange (WS-RX) OASIS Technical Committee recently
published the WS-ReliableMessaging (WS-RM) specification for public
review. This article discusses how the new specification addresses
the issue of delivering SOAP messages to an endpoint that can not
accept incoming connections and examines its overlapping
functionality with the Web Services Polling (WS-Polling) specification.
During the course of its work, the WS-RX Technical Committee (TC) ran
into a problem that many people are also encountering: delivering SOAP
messaging to an endpoint that, for any number of reasons, can't accept
new incoming connections. For the WS-RM specification, this is
particularly troublesome since a key component of its processing model
is the ability for a sending endpoint to retransmit, at its own
discretion, unacknowledged messages to the destination endpoint. This
article provides an extensive examination of the MakeConnection
feature, along with the rationale behind some of its design decisions,
and the possible impact on existing SOAP implementations, reinforces
the idea that MakeConnection is not a polling feature, but rather
simply another transport mechanism by which a SOAP message can be
transferred between endpoints. And, given the impact that WS-Addressing
has already had on SOAP implementations, support for MakeConnection
shouldn't be as radical a change as it may initially appear.
See also: reliable messaging references
Roadmap for Accessible Rich Internet Applications (WAI-ARIA Roadmap)
Richard Schwerdtfeger and Jon Gunderson (eds), W3C Technical Report
W3C's Protocols and Formats Working Group has released First Public
Working Drafts for Accessible Rich Internet Applications (WAI-ARIA).
The "Roadmap for Accessible Rich Internet Applications" addresses the
accessibility of dynamic Web content for people with disabilities. The
roadmap outlines the technologies to map controls, AJAX live regions,
and events to accessibility APIs, including custom controls used for
Rich Internet Applications. The roadmap also outlines new navigation
techniques to mark common Web structures as menus, primary content,
secondary content, banner information and other types of Web structures.
These new technologies can be used to improve the accessibility and
usability of Web resources by people with disabilities, without
extensive modification to existing libraries of Web resources. The
"Roles for Accessible Rich Internet Applications (WAI-ARIA Roles)"
document describes tools that provide alternate modes of access for
people with disabilities by transforming complex user interfaces into
an alternate presentation. This transformation requires information
about the role, state, and other semantics of specific portions of a
document to be able to transform them appropriately. Rich Web
applications typically rely on hybrid technologies such as DHTML and
AJAX that combine multiple technologies: SVG, HTML and JavaScript for
example. The various technologies provide much but not all of the
information needed to support AT adequately. This specification
provides a Web-standard way to identify roles in dynamic Web content.
The result is an interoperable way to associate behaviors and
structure with existing markup. The draft "States and Properties Module
for Accessible Rich Internet Applications (WAI-ARIA States and
Properties)" defines attributes that enable XML languages to add
information about the behavior of an element. States and Properties
are mapped to accessibility frameworks (such as a screen reader) that
use this information to provide alternative access solutions. Similarly,
States and Properties can be used to change the rendering of content
dynamically using different style sheet properties. The result is an
interoperable method for associating behaviors with document-level
markup.
See also: the W3C announcement
Oracle Unveils First Core Berkeley DB Release
China Martens, InfoWorld
Oracle is releasing its first version of the core Berkeley DB embedded
database since acquiring the software through its February purchase of
open-source developer Sleepycat Software. Oracle is due to make
Berkeley DB release 4.5 generally available on Wednesday. The focus is
around improving performance, availability, and ease of use, according
to Rex Wang, vice president of embedded systems marketing at Oracle and
Sleepycat's former vice president of marketing. The new functionality
was already on the road map at Sleepycat. First developed in 1991,
Berkeley DB is the core version of the Sleepycat embedded database, but
the open-source vendor also began offering XML and Java versions of its
database in recent years. Oracle already put out a new release of
Berkeley DB Java Edition, version 3.0, in May and plans a refresh of
Berkeley DB XML shortly. New in Berkeley DB release 4.5 are the ability
for users to upgrade or patch a replicated Berkeley DB without having to
take the entire system down, multiversion concurrency controls to handle
changes being made to the database by many users, and a replication
framework to help developers build highly available systems.
See also: XML and Databases
Public Review for the OASIS Functional Elements Specification
Tan Puay Siew (ed), OASIS Committee Draft
Members of the OASIS Framework for Web Services Implementation (FWSI)
Technical Committee recently approved its "Functional Elements
Specification Version 2.0, Committee Draft 3" as appropriate for
public review. The TC encourages feedback from potential users,
developers and others through 06-October-2006. From the specification
Abstract: "The ability to provide robust implementations is a very
important aspect to create high quality Web Service-enabled applications
and to accelerate the adoption of Web Services. The Framework for Web
Services Implementation (FWSI) TC aims to enable robust implementations
by defining a practical and extensible methodology consisting of
implementation processes and common functional elements that
practitioners can adopt to create high quality Web Services systems
without reinventing them for each implementation. This document
specifies a set of Functional Elements for practitioners to instantiate
into a technical architecture, and should be read in conjunction with
the Functional Elements Requirements document. It is the purpose of
this specification to define the right level of abstraction for these
Functional Elements and to specify the purpose and scope of each
Functional Element so as to facilitate efficient and effective
implementation of Web Services.
See also: the announcement
Introduction to XForms, Part 3: Using Actions and Events
Chris Herborth, IBM developerWorks
XForms is the next generation of Web-based data processing. It replaces
traditional HTML forms with an XML data model and presentation elements.
It is gaining momentum rapidly, with support available for common
browsers using extensions or plugins. Its flexibility and power make
it attractive to Web developers, and its small footprint and client-side
processing, make it attractive to systems administrators. The W3C is
currently reviewing XForms 1.1 as a Working Draft document (1.0 is an
official Internet Recommendation, which puts it on par with things like
XHTML, PNG, and CSS), and IBM is currently spearheading an effort to
merge competing XML-based forms standards with the features and
abilities of XForms. This article, a third in the series, shows you
how to use actions and events with XForms, and how to control the format
of the form's output. XForms uses the XML Events standard to attach event
handlers to specific elements in a document. XML Events is an XML
representation of the DOM event model from HTML. When an event occurs
(a click or a mouse-over, for example) the capture phase begins.
Starting at the root of the document tree and moving down to the element
where the event was triggered, each element is given the opportunity to
handle the event. If the event reaches the target element without being
handled and the event type allows it, the bubbling phase begins. The
event travels back up the tree towards the document root. Elements can
be observers; the observer's event handler will be activated as the
event passes through in both directions. An event handler can only
listen to one phase, so you need to attach two handlers to an element
if you want to do something during each phase.
See also: XML and Forms
Evaluation and Report Language (EARL) 1.0 Schema
Shadi Abou-Zahra and Charles McCathieNevile (eds), W3C Working Draft
W3's Evaluation and Repair Tools Working Group has released a Working
Draft of the "Evaluation and Report Language (EARL) 1.0 Schema, updating
the WD of 2005-09-09. It describes the formal schema of the Evaluation
and Report Language (EARL) 1.0. The Evaluation and Report Language is
a standardized vocabulary to express test results. The primary
motivation for developing this language is to facilitate the exchange
of test results between Web accessibility evaluation tools in a vendor
neutral and platform independent format. It also provides reusable
vocabulary for generic quality assurance and validation purposes. EARL
is a flexible format used to exchange, combine and compare various kinds
of test results, including bug reports, test suite evaluations and
conformance claims. The test subjects might be Web sites, authoring
tools, user agents or other entities. The Working Group welcomes
feedback from Web developers and researchers.
See also: W3C's Web Accessibility Initiative (WAI)
AJAX Survey Shows Trend Toward Consolidation
Darryl K. Taft, eWEEK
Ajaxian.com, a Web community focused on Asynchronous JavaScript and
XML-style development issues, has released its second annual survey,
which indicates that open-source frameworks are most popular with
developers. The survey, which polled 865 participants, showed that the
Prototype AJAX framework was most popular among respondents, with 43
percent of developers saying they preferred it over others. Next was
Script.aculo.us with 33 percent, the Dojo Toolkit with 19 percent, and
DWR (Direct Web Remoting) with 12 percent, rounding out the top four
slots. Richard Monson-Haefel, a senior analyst with Midvale, Utah-
based Burton Group, prepared the survey for Ajaxian. The survey allowed
for multiple responses per participant. Meanwhile, completing the list
of results, 11 percent of the respondents said they liked the Moo.fx
framework, jQuery had 7 percent, Yahoo UI (Yahoo User Interface Library)
had 5 percent, and Rico brought in 5 percent. After that Mochikit,
XAJAX and Microsoft's Atlas toolkit — recently renamed to ASP.NET 2.0
AJAX Extensions — each had 4 percent. And Google's relatively new GWT
(Google Web Kit) came in last with 3 percent of developers polled
saying they preferred it. The Ajaxian survey also got results on what
developers considered their favorite server-side platform. PHP was the
clear winner in this category, with 50 percent of the responses. Java
was second at 37 percent, .Net had 16 percent, Ruby on Rails had 14
percent, Python had 6 percent, and ColdFusion and Perl both had 5
percent. And between 2 percent and 4 percent are using Adobe's Flex in
some way, the survey results showed.
XML.org is an OASIS Information Channel
sponsored by BEA Systems, Inc., IBM Corporation, Innodata Isogen, SAP AG and Sun
Microsystems, Inc.
Use http://www.oasis-open.org/mlmanage
to unsubscribe or change an email address. See http://xml.org/xml/news_market.shtml
for the list archives. |
