Cover Pages: XML Daily Newslink: Thursday, 12 April 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:
Primeton http://www.primeton.com

Headlines

Internationalization Best Practices: Specifying Language in XHTML and HTML Content
OASIS Forms Open Composite Services Architecture Member Section
Report Reveals AJAX on the Rise
WS-BPEL 2.0 Ratified as an OASIS Standard
Managing XML Vocabulary Revisions: A Smoother Change to Version 2.0

Internationalization Best Practices: Specifying Language in XHTML and HTML Content
Richard Ishida (ed), W3C Technical Report

Members of the W3C Internationalization Core Working Group have published "Internationalization Best Practices: Specifying Language in XHTML and HTML Content" as a Working Group Note. The document is part of a series and written for HTML content authors working with XHTML 1.0, HTML 4.01, XHTML 1.1, and CSS. Specifying the language of content is useful for a wide number of applications, from linguistically-sensitive searching to applying language-specific display properties. In some cases the potential applications for language information are still waiting for implementations to catch up, whereas in others, such as detection of language by voice browsers, it is a necessity today. On the other hand, adding markup for language information to content is something that can and should be done today. Without it, it will not be possible to take advantage of any future developments. Applications already exist that can use information about the natural language (i.e., the human, non-programmatic language) of content to deliver to users the most relevant information or styling, based on their language preferences. The more content is tagged and tagged correctly, the more useful and pervasive such applications will become. Language information is useful for things such as authoring tools, translation tools, accessibility, font selection, page rendering, search, and scripting. These applications can't work, however, if the information about the language of the text is not available. Language information should therefore be specified for the page as a whole, and wherever language changes within the page. In the future there will be other applications for language information, driven by developments in technology. For example, implementations of the CSS3 ':first-letter' pseudo-element will need language information to apply correct styling.

See also: Markup and Multilingualism

OASIS Forms Open Composite Services Architecture Member Section
Staff, OASIS Announcement

OASIS recently announced the formation of the Open Composite Services Architecture (Open CSA) Member Section, a new initiative to advance standards that simplify Service Oriented Architecture (SOA) application development. Open CSA will promote the further development and adoption of the Service Component Architecture (SCA) and Service Data Objects (SDO) families of specifications, which will be provided to the community on a Royalty Free basis. SCA helps organizations more easily design and transform IT assets into reusable services that can be rapidly assembled to meet changing business requirements. SDO lets application programmers uniformly access and manipulate data from heterogeneous sources, including relational databases, XML data sources, Web services, and enterprise information systems. Both SCA and SDO were created by the Open SOA Collaboration, an informal group of 18 software vendors. After successfully shepherding the specifications through their incubation phase, these vendors selected OASIS as the most effective venue for advancing SCA and SDO through the open standardization process. The Open CSA Member Section will oversee several new OASIS Technical Committees for the SCA and SDO families of specifications.

See also: the OSOA submission

Report Reveals AJAX on the Rise
Jeffrey Schwartz, Application Development Trends

There are now 3.5 million AJAX developers worldwide, a 50 percent increase over the past year, based on results of a survey conducted by Santa Cruz, Calif.-based Evans Data Corp.. The survey will also reveal that nearly four out of five, or 78 percent of AJAX applications are developed for the Web and nearly 40 percent are for server-centric applications such as databases, ERP, CRM, as well as rich Internet applications. Overall the study shows that AJAX (Asynchronous JavaScript and XML) is rapidly becoming a key technology for the Web, as well as mashups, composite applications that draw data from multiple sources. AJAX was made popular over two years ago by Google Maps, which, unlike other map sites, gives users the ability to pull down data when they point their mouse to a particular location. Glenn Barnett, engagement manager at Boston-based Molecular, said half of the RFPs he receives are looking for some form of rich Internet application functionality, up from less than 20 percent a few years ago. That said, he still encounters reluctance by many companies to run AJAX and Flash within enterprises. "It is rapidly growing but the people who are into it now are those enthusiastic about technology and pushing the edge and being innovative," Barnett said. "The rank and file commoditized applications aren't going to be using what we refer to as Web 2.0 techniques for the next few years."

WS-BPEL 2.0 Ratified as an OASIS Standard
Staff, OASIS Announcement

OASIS announced that its members have approved the Web Services Business Process Execution Language (WS-BPEL) version 2.0 as an OASIS Standard, a status that signifies the highest level of ratification. WS-BPEL uses Web services standards to describe business process activities as Web services, defining how they can be composed to accomplish specific tasks. WS-BPEL defines a model and a grammar for describing the behavior of a business process based on interactions between the process and its partners. The interaction with each partner occurs through Web services interfaces. The WS-BPEL process defines how multiple service interactions with these partners are coordinated to achieve a business goal, as well as the state and the logic necessary for this coordination. WS-BPEL separates the public aspects of business process behavior from internal or private aspects-and supports both. The standard can be used both for executable processes, which describe the actual behavior of participants in business interactions, and for abstract processes, that may be used to represent publicly observable behaviors. Abstract processes serve a descriptive role and allow for more than one possible use case. WS-BPEL leverages other Web services standards such as SOAP and WSDL for communication and interface description. By describing the inbound and outbound process interfaces in WSDL, BPEL enables them to be easily integrated into other processes or applications. In turn, this allows consumers of a process to inspect and invoke a BPEL process just like any other Web service, thereby inheriting all other aspects of a Web service such as quality of service policies.

See also: the OASIS TC

Managing XML Vocabulary Revisions: A Smoother Change to Version 2.0
Marc de Graauw, XML.com

When moving to the 'next version' of an XML-based exchange, we want a smooth transition. However, this is not easy: on one hand, we want old version processors to accept new messages, the way older browsers can display newer HTML by ignoring unknown tags. On the other hand, those "mustIgnoreUnknown" semantics are often unwanted. In financial transactions, medical care, justice, etc., certain parts must always be understood—we'd rather have a physician grab the phone and call us than have him ignore those parts about lethal allergies that his client software did not understand. SOAP provides a mechanism for SOAP headers: a "mustUnderstand" flag, which indicates which parts may not be ignored. Unfortunately, this mechanism is rather inflexible. This article outlines a design pattern that makes a version transition much easier, and that is both more powerful and simpler than SOAP-style "mustUnderstand" semantics. The Capability Compatibility Design Pattern is a very flexible and powerful way to control changes in versions of languages for exchanges over the Internet. It goes beyond SOAP-style mustUnderstand headers and easily supports IgnoreUnknown and mustUnderstand semantics for elements, attributes, and enumerations. It does this all by adhering to two simple principles: (1) List all versions, including older ones, that you know may process your message inside the message you make; (2) Know all versions you support, and check whether they fit requirements in incoming messages.


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

Headlines

Sponsors