The Cover PagesThe OASIS Cover Pages: The Online Resource for Markup Language Technologies
Advanced Search
Site Map
CP RSS Channel
Contact Us
Sponsoring CP
About Our Sponsors

Cover Stories
Articles & Papers
Press Releases

XML Query

XML Applications
General Apps
Government Apps
Academic Apps

Technology and Society
Tech Topics
Related Standards
Last modified: October 24, 2007
XML Daily Newslink. Wednesday, 24 October 2007

A Cover Pages Publication
Provided by OASIS and Sponsor Members
Edited by Robin Cover

This issue of XML Daily Newslink is sponsored by:

Setting Out for Service Component Architecture
Henning Blohm, InfoQ

Quite a number of bloggers have been wondering about the Service Component Architecture (SCA) standardization effort. SCA's pick-and-chose specification style makes it is easy to get lost in the SCA universe. Because there is little experience with using SCA in the community, many areas that deserve detailed specification are still under investigation or have not even been touched yet. At first, readers might easily be misled into believing that SCA is (yet another) revolution in Java land. This is wrong on two counts. Firstly, although Java oriented work attract most of the attention, SCA is not only about Java land: there are specifications for C++, COBOL, PHP, and BPEL. What we want to focus on though is that SCA is not primarily about replacing existing environments (such as Java EE and OSGI) but about creating an infrastructure in which applications can cross the boundaries between different programming model in these environments. The details of how SCA will integrate with existing technologies are the missing pieces in the catalogue of published SCA specifications. There is simply still a lot of work ahead to figure out the tedious details of integration at all layers with these environments. Technology integration is hard. No single interesting technology should be limited in its use. And yet, SCA is all about cross-technology integration... SCA defines an assembly language that may be integrated into such frameworks in order to realize a number of benefits. We will discuss various benefits in detail. Here are the claims we will make: (1) SCA can be supported in conjunction with existing technologies. That will likely be its primary use-case. (2) SCA's fundamental value lies in providing the foundation to cross-technology programming model integration, distributed deployments and assembly. (3) SCA will allow implementers to provide proprietary technologies in a consistent and recognizable way—which is good for both developers and vendors.

See also: the Open CSA Member Section

Behavioral Extensions to CSS
Ian Hickson (ed), W3C Technical Report

W3C announced the release of an updated version of the "Behavioral Extensions to CSS" Working Draft. The document was produced by members of the W3C CSS (Cascading Style Sheets) Working Group as part of the Style Activity. In 1999, the CSS working group worked on a "Behavioral Extensions to CSS" specification that proposed syntax for actual binding definitions. Since then, separate languages have been developed for this purpose (e.g. XBL), and the CSS-specific way of defining bindings has been dropped. CSS is still useful for connecting these binding languages to actual elements, however. This specification defines two features of CSS that can be used with any such binding language. Behavioral Extensions provide a way to link to binding technologies, such as XBL, from CSS style sheets. This allows bindings to be selected using the CSS cascade, and thus enables bindings to transparently benefit from the user style sheet mechanism, media selection, and alternate style sheets. A "binding" is a definition of presentation or behavior that can be attached to an element, and bindings can be attached to elements through CSS using the 'binding' property. Bindings attached through CSS must only remain on the bound element as long as the element continues to match the style rule. If at any time a resolution of style on the element determines that a different binding should be attached, the old binding must be detached. Whenever an element is removed from a document, any bindings attached to that element via CSS must be detached. The ":bound-element" pseudo-class, when used from a binding, must match the bound element of that binding. If the selector is used in a context that is not specific to a binding, then it must match any bound element. One example shows an XBL binding that uses this pseudo-class to to draw a border around each of the children of the bound element, but no other elements.

See also: the style discussion list

CSS Snapshot 2007: W3C Working Draft
Elika J. Etemad (ed), W3C Technical Report

W3C's CSS Working Group recently published the First Public Working Draft for "Cascading Style Sheets (CSS) Snapshot 2007." The document collects together into one definition all the specs that together form the current state of Cascading Style Sheets (CSS). All stable specifications that have been implemented for the Cascading Style Sheets (CSS) language at all Levels are given in this single document as a guide for authors. The snapshot is not a guide to what features are implemented. The group expects it to be a future Working Group Note. When the first CSS specification was published, all of CSS was contained in one document that defined CSS Level 1. CSS Level 2 was defined also by a single, multi-chapter document. However for CSS beyond Level 2, the CSS Working Group chose to adopt a modular approach, where each module defines a part of CSS, rather than to define a single monolithic specifcation. This breaks the specification into more manageable chunks and allows more immediate, incremental improvement to CSS. Since different CSS modules are at different levels of stability, the CSS Working Group has chosen to publish this profile to define the current scope and state of Cascading Style Sheets as of late 2007. The profile includes only specifications that we consider consider stable and for which we have enough implementation experience that we are sure of that stability. The CSS Working Group considers the CSS1 specification to be obsolete. CSS 2.1 is now a Candidate Recommendation—effectively though not officially the same level of stability as CSS2—and should be considered to obsolete the CSS2 Recommendation. In case of any conflict between the two specs CSS 2.1 contains the definitive definition. Features in CSS2 that were dropped from CSS 2.1 should be considered to be at the Candidate Recommendation stage, but note that many of these have been or will be pulled into a CSS Level 3 working draft, in which case that specification will, once it reaches CR, obsolete the definitions in CSS2. CSS Level 3 builds on CSS Level 2 module by module, using the CSS 2.1 specification as its core. Each module adds functionality and/or replaces part of the CSS 2.1 specification. The CSS Working Group intends that the new CSS modules will not contradict the CSS 2.1 specification: only that they will add functionality and refine definitions. As each module is completed, it will be plugged in to the existing system of CSS 2.1 plus previously-completed modules.

See also: the CSS Working Group

SMI-S: A Standard That Leaves Out the Good Stuff?
Bruce Hoard, Computerworld

The Storage Management Initiative Specification (SMI-S) is a lightning rod for controversy among both its supporters and detractors. It has been approved by the ISO international standards organization and the International Electrotechnical Commission (IEC) as a standard for interoperable storage management technologies. Yet detractors say SMI-S was overhyped and will never fulfill its original promise of integrating storage device management across the industry. Supporters continue to say SMI-S is opening storage resource management (SRM) doors that were previously locked by proprietary vendors. SMI-S, now in Version 1.02, grew out of the Storage Management Initiative (SMI), which was created by the Storage Networking Industry Association (SNIA) in 2002. SMI-S is criticized for not being more open to smaller SRM vendors and failing to help end user IT organizations establish centralized control over their heterogeneous storage infrastructures because larger vendors will not port the most sophisticated application programming interfaces (API) to the standard's framework. Many large members of the vendor trade group say that even though SMI-S implementations have lagged behind the rapidly evolving standard, both vendors and users are benefiting from it. The basic concept behind SMI-S is simple: Vendors translate product specifications into XML code for their specific storage management software, which creates a universal API that can be accessed by any other SMI-S-compatible products. SNIA says that about 450 products from 30 vendors have so far passed the SNIA Conformance Testing Program for SMI-S. Product types include storage networking components (such as arrays, switches and host bus adapters) and their associated management software, as well as client software.

See also: earlier SMI-S references

Microsoft to Showcase Interoperability Technologies
Peter Galli, eWEEK

Microsoft is using Interop New York to showcase the interoperability work from its collaboration with the 50 software and hardware vendors that are members of the Interoperability Vendor Alliance it sponsors. The technologies from the work of the Alliance's technical labs and being shown at Interop the week of October 22, 2007 are used to streamline the management of heterogeneous systems, including Linux, Oracle, JBoss, SAP, Windows and SQL Server. Microsoft, of Redmond, Wash., also worked with CA, Oxford Computer Group and other industry vendors under the federated identity initiative to create step-by-step lab guides to demonstrate cross-product federation. Meridio, Open Text, Vorsite, SchemaLogic and Microsoft also collaborated on advancing portal document repository collaboration that lets companies identify, move, search and collaborate on documents across portals and repositories. Microsoft's objective was to find the issues its customers cared most about and then work internally with them, its partners and other vendors to address those issues, he said. The 41-member Interoperability Executive Customer Council, which Microsoft set up in June 2006, is addressing more than 60 percent of all issues identified by its customers and has made progress in four areas: office productivity and collaboration tools; developer tools and run-time; security and identity management; and systems management.

Atom Publishing Protocol Published
Paul Krill, InfoWorld

The Atom Publishing Protocol, an application-level protocol for publishing and editing Web resources, has now been published. Based on HTTP transfer of Atom-formatted representations, the Atom format is documented in the Atom Syndication Format. Atom development was motivated by the presence of many incompatible versions of the RSS syndication format, which had poor interoperability for XML-RPC-based publishing protocols. Published as an Internet Engineering Task Force proposed standard as RFC (Request for Comment) 4287, it was published as RFC 5023. Atom is important because it will make it easier to post to the Web, according to Tim Bray, director of Web technologies at Sun, who co-chaired the standard: "Here at Sun, in a blogging-friendly tech-savvy culture, maybe 5 percent of the people post regularly. So I look at the number of people using the Net and I wonder, why aren't there 50 million, instead of five million, people contributing every week? The answer: because it's too hard. We can fix that," Bray said. "Here's the Atom dream: a "publish' button on everything," Bray said. "On every word processor and email reader and Web browser and cell phone and PDA and spreadsheet and photo-editor and digicam and outliner and sales-force tracker. Really, everywhere. If it doesn't have a 'Publish' button, it's broken." The AtomPub WG was chartered to work on the syndication format in RFC 4287 and the publishing protocol in RFC 5023. Implementations of these specifications work together and interoperate well to support publishing and syndication of text content and media resources.

See also: the final APP specification

Google Search Appliance Version 5.0 Features SAML-Based Security
Matthew Glotzbach, Google Enterprise Announcement

Google Enterprise Labs announced the release of the Google Search Appliance Version 5.0, featuring enhanced security for enterprise applications. The Google Search Appliance provides document and user-level access control across all web-enabled enterprise content to ensure that users only see search results for documents they're permitted to access. With version 5.0, the designers made significant performance improvement to the SAML SPI framework; as a result the customers who leverage SAML SPI will be improved performance on their secured search queries. If the search appliance is configured to use the SAML Authentication and Authorization SPI, the search appliance sends a SAML authorization request to the Policy Decision Point, using the identity obtained for the user during serve authentication. The SPI enables a Google Search Appliance to communicate with an existing access control infrastructure via standard SAML messages. The Authorization SPI is also required in order to support X.509 certificate authentication during serve. When the user's identity has been authenticated, the Authorization SPI checks to see whether the user is authorized to view each of the secure documents that match their search. Using the authenticated cookie set during Authentication, the search appliance passes the user's session cookie to the Policy Decision Point's Authorization Service URL inside a SAML Authorization request. If the response from the Policy Decision Point is inconclusive, the search appliance will also attempt to verify authorization with a HEAD request (for content crawled via HTTP Basic or NTLM HTTP) or GET request (for content crawled via Forms Authentication) before removing the content from the search results list. The "Windows Authentication via Google SAML Bridge for Windows" is a special case of the Authentication and Authorization SPI. The search appliance sends SPI messages to the Google SAML Bridge for Windows to verify the user's credentials and authorization to view secure content. This method requires you to set up the Google SAML Bridge for Windows to handle the SAML messages from the search appliance's Authorization and Authentication SPI. The Google SAML Bridge for Windows acts as an Identity Provider and Policy Decision Point.

See also: Google Apps SAML SSO

The Trouble With XML Schema Imports and Includes
Anthony B. Coates, Blog

Those who have written W3C XML Schemas will know that there are two mechanisms for sharing Schema definitions across files. "xs:include" is used like traditional programming language 'include' statements, so that you can split a single large file up into separate, modular pieces. "xs:import" is used when you need to use Schema definitions from a different XML namespace, as W3C XML Schema doesn't allow a single Schema file to contain definitions for more than a single namespace... I have been involved with a number of standards groups, and I know that the what comes out of a standards effort depends on what requirements and scope have been given to the group. So while I wish that the W3C's XML Schema Working Group had been able to give us something better for Schema definition sharing than just import/include statements, I don't think the working group ever had a scope that would have allowed them, for example, to define a standard for repositories of Schema definitions, and for how to compose and generate Schemas flexibly from the definitions in one or more repositories. Instead, we have import and include, which are about the best you can do when your scope only allows you to deal with schemas, and not with higher-level concepts like repositories. As a general rule, almost any solution will work if the problem is simple enough and straightforward enough and isn't particularly demanding in any way. Many uses of import/include statements are simple enough that these built-in mechanisms do what is needed. However, there are other situations where import/include don't work as you would hope, and I thought I would mention a couple that I have run into in practice...

Google Product Chief: It's Okay to Fail Wisely
Clint Boulton, eWEEK

Traditional methods of innovation are changing, forcing businesses to move away from wielding a sustainable competitive advantage to bursts of continuous innovation and especially collaboration. This collaborative innovation will spur new products and services. That was one of the messages from Matt Glotzbach, product management director for Google Enterprise, who discussed the need for changes in the way companies facilitate innovation during his keynote at the Interop New York show on October 24, 2007. Glotzbach said the notion of creating a product, subjecting it to all kinds of tests, and sitting on it for years before releasing it is antiquated. Illustrating his point, Glotzbach announced that Google, of Mountain View, Calif., on Oct. 24 began rolling out free IMAP (Internet Message Access Protocol) for the company's Gmail Web mail application. IMAP keeps the same information synched across mobile phones, PDAs or desktops so that whatever work users do in one place shows up wherever they might access their e-mail. Glotzbach showed a picture of how he used IMAP to synchronize his e-mail account with his iPhone. In another example, Glotzbach told the audience Google encourages its employees to use 20 percent of their time, or one day a week, to work on projects outside of their normal everyday workflow. Glotzbach also said that while the high tech industry used to pride itself on innovation driven from the enterprise out to the consumers, it is the consumer that is now wagging the dog. For example, Google Apps was conceived as a consumer-oriented product, but Glotzbach's group is managing to get 1,500 businesses a day to sign up to try it as a complement or even an alternative to Microsoft Office. Users can expect Apps updates every other week.


XML Daily Newslink and Cover Pages are sponsored by:

BEA Systems, Inc.
IBM Corporation
Sun Microsystems, Inc.

XML Daily Newslink:
Newsletter Archive:
Newsletter subscribe:
Newsletter unsubscribe:
Newsletter help:
Cover Pages:

Hosted By
OASIS - Organization for the Advancement of Structured Information Standards

Sponsored By

IBM Corporation
ISIS Papyrus
Microsoft Corporation
Oracle Corporation


XML Daily Newslink
Receive daily news updates from Managing Editor, Robin Cover.

 Newsletter Subscription
 Newsletter Archives
Globe Image

Document URI:  —  Legal stuff
Robin Cover, Editor: