This issue of XML Daily Newslink is sponsored by:
Internationalization Best Practices: Specifying Language in XHTML and
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
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.
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: email@example.com
Newsletter unsubscribe: firstname.lastname@example.org
Newsletter help: email@example.com
Cover Pages: http://xml.coverpages.org/