Cover Pages: XML Daily Newslink: Monday, 21 December 2009

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:
Microsoft Corporation http://www.microsoft.com

Headlines

W3C Invites Implementations of Cascading Style Sheets (CSS) Specifications
OGF Releases Experimental Document on WS-DAI and WS-DAIR Implementations
IETF Informational RFC Published for The rsync URI Scheme
IBM Adds Support for XPath 2.0, XSLT 2.0 and XQuery 1.0 to WebSphere 7
Common Sense Guidelines for Using XQuery with Native XML Databases
Triple-Parity RAID and Beyond

W3C Invites Implementations of Cascading Style Sheets (CSS) Specifications
Staff, W3C Announcement

Members of the W3C Cascading Style Sheets (CSS) Working Group now invite implementation of two Candidate Recommendation specifications: "CSS Multi-column Layout Module" and "CSS Backgrounds and Borders Module Level 3."

CSS is a language for describing the rendering of structured documents (such as HTML and XML) on screen, on paper, in speech, etc. It is playing an important role in styling not just HTML, but also many kinds of XML documents: XHTML, SVG (Scalable Vector Graphics) and SMIL (the Synchronized Multimedia Integration Language), to name a few. It is also an important means of adapting pages to different devices, such as mobile phones or printers...

"CSS Multi-column Layout Module" describes how content can be flowed into multiple columns with a gap and a rule between them. On the Web, tables have also been used to describe multi-column layouts. The main benefit of using CSS-based columns is flexibility; content can flow from one column to another, and the number of columns can vary depending on the size of the viewport. Removing presentation table markup from documents allows them to more easily be presented on various output devices including speech synthesizers and small mobile devices... This document will remain at Candidate Recommendation stage at least until 17-June-2010. For this specification to be proposed as a W3C Recommendation, the following conditions shall be met: there must be at least two independent, interoperable implementations of each feature. Each feature may be implemented by a different set of products, so there is no requirement that all features be implemented by a single product...

"CSS Backgrounds and Borders Module Level 3" presents the features of CSS level 3 relating to borders and backgrounds. It includes and extends the functionality of CSS level 2, which builds on CSS level 1. The main extensions compared to level 2 are borders consisting of images, boxes with multiple backgrounds, boxes with rounded corners and boxes with shadows. When elements are rendered according to the CSS box model, each element is either not displayed at all, or formatted as one or more rectangular boxes. Each box has a rectangular content area, a band of padding around the content, a border around the padding, and a margin outside the border. The margin may actually be negative, but margins have no influence on the background and border... This document will remain at Candidate Recommendation stage at least until 17-June-2010.

OGF Releases Experimental Document on WS-DAI and WS-DAIR Implementations
Steven Lynden, Mario Antonioletti (et al, eds); OGF Final Specification

The Open Grid Forum (OGF) announced publication of "WS-DAI and WS-DAIR Implementations: Experimental Document" (GFD-E.160), which presents the results of the interoperability testing process of two independent implementations of the WS-DAI and WS-DAIR specifications. The document was produced by members of the OGF Database Access and Integration Services WG (DAIS-WG).

"Web Services Data Access and Integration: The Core (WS-DAI)" presents a specification for a collection of generic data interfaces developed by the Database Access and Integration Services (DAIS) Working Group that can be extended to support specific kinds of data resources, such as relational databases, XML repositories, object databases, or files. Related specifications define how specific data resources and systems can be described and manipulated through such extensions. The specifications can be applied in regular web services environments or as part of a grid fabric. "Web Services Data Access and Integration: The Relational Realisation (WS-DAIR)" specifies a collection of data access interfaces for relational data resources, which extends interfaces defined in WS-DAI...

Abstract for GFD-E.160: "The Data Access and Integration Services (DAIS) Working Group have defined three proposed recommendations within the Open Grid Forum (OGF). The OGF process and requirements document states that two independent interoperable implementations are required for a proposed recommendation to become a full OGF recommendation. This OGF experimental document reports on interoperability testing of two implementations of WS-DAIR (GFD.76)—one from the OGSA-DAI1 group at The University of Edinburgh and the other based on AMGA2 from KISTI. In addition, as the WS-DAIR proposed recommendation is an extension to WS-DAI (GFD.74), the testing process has encompassed both the WS-DAIR and WS-DAI proposed recommendations.

The tests documented in this OGF experimental document establish that it is indeed possible to obtain client-based interoperability for these two implementations. However, as a result of this interoperation process a number of changes are recommended for the WS-DAI and WS-DAIR documents before they gain full recommendation status. It is important to note that this document establishes a set of interoperability requirements between two or more implementations of the WS-DAI specifications, taking into account the criteria established in GFD.77 (Interoperabuility). This document is not intended to establish a validation process to test the compliance of any particular implementation to any of the (proposed) DAIS recommendations..."

See also: the OGF Document Series

IETF Informational RFC Published for The rsync URI Scheme
Samuel Weiler, Dave Ward, Russ Housley; IETF Internet Draft

The Internet Engineering Steering Group (IESG) announced approval of "The rsync URI Scheme" as an IETF Informational RFC. The document specifies the rsync Uniform Resource Identifier (URI) scheme.

"URIs were previously defined in RFC 2396, which was updated by RFC 3986. The procedures for registering new URI schemes are defined in RFC 4395. This rsync URI scheme is already in active use in the world, but it has never been registered with IANA. The document therefore makes a provisional registration of the URI scheme that's already in use. An rsync URI describes a source or destination for the rsync application including a hostname, path, and optional user and port.

An rsync URI may be used as either a source or destination for the rsync application. If the port is not specified, it defaults to 873. Since the rsync URI is defined using standard elements from RFC 3986, no special encoding considerations are present.

Many security considerations for the usage of URIs are discussed in Section 7 of RFC 3986. The considerations about reliability and consistency, malicious construction, rare IP address formats, sensitive information, and semantic attacks all apply to rsync URIs. The considerations about transcoding do not apply. The rsync URI scheme has no particularly unique security considerations..."

IBM Adds Support for XPath 2.0, XSLT 2.0 and XQuery 1.0 to WebSphere 7
Charles Humble, InfoQueue

"IBM's WebSphere feature packs are optionally installable product extensions to the application server offering new features. IBM's recently released Feature Pack for XML provides application developers with support for the most recently ratified set of W3C XML standards, including XQuery 1.0 (a newly introduced query and functional programming language designed to query collections of XML data), XPath 2.0 (an expression language for working with XML documents), and XSLT 2.0 (a programming language used to transform XML into a new XML format, or into another presentation format such as HTML, XHTML or SVG).

IBM chief Architect Andrew Spyker: "Given XML is so popular in enterprise computing it's very hard to talk about every scenario in which this feature pack will be used... While XQuery has been supported for some time in databases that support XML natively (DB2 pureXML for example), having XQuery support in the middleware allows data to be joined between these XML databases and XML stores that exist outside of the database. An example would be a batch file that worked with data in an XML database, enriched it with calls to Web 2.0 APIs, and then stored it in a second database. The XML Feature Pack supports this scenario with the thin client which can be used outside of a server JVM in a standard Java SE application, as long as it's used in support of the Application Server functionality...

There are two main advantage of working with declarative (vs. imperative) XML centric (vs. language centric) languages such as those supported in the XML Feature Pack. First declarative programming asks the user what they want to do. This is as opposed to imperative programming (example: Java code working with the DOM or JAXB APIs) which asks the user how they want to do what they want to do. Declarative programming leads to smaller, easier to maintain code that adapts faster to change... Second, XML centric (vs. Java or C# or some other language) is all about having the XML type system as the core type system... I should note that we understand that people won't change entire existing applications over to XML programming models. Therefore, we allow an easy way to add existing Java data and logic to the XML runtime execution. This extension is done through the same consistent API regardless of which XML language is being used..."

Common Sense Guidelines for Using XQuery with Native XML Databases
Donnie Camero, IBM developerWorks

RSS, Atom, mashups, extraordinary search requirements and other developments are making native XML databases an important part of search applications and services. These types of databases excel at efficiently searching through large collections of semi-structured data. This article presents some common sense guidelines to maximize the performance of applications that use XQuery and native XML databases.

Using XQuery (a functional language designed to query collections of XML data) with native XML database systems can be extremely useful in some situations. When servicing queries that are complex and mostly read-only, compared to standard relational databases, native XML databases provide faster response times and faster development times. With the simplest and most powerful data-transformation system available today built right into the query language, you gain faster development times because you don't need to design a separate full-text indexing system or assemble much of the data for the user.

At the cost of slower inserts and updates, native XML databases can provide vastly superior out-of-the-box response times because they keep their data largely denormalized, provide default indexes, and make excellent use of available RAM. However, when dealing with very large data sets, you can further improve the query response times of a native XML database by following these guidelines; the guidelines are general and applicable to many of the native XML databases that are available today, including IBM DB2 Express-C, Mark Logic Server, eXist, and even Oracle Berkeley DB XML: (1) Avoid normalization; (2) Employ unique element names; (3) Precompute values; (4) Transform data with your queries; (5) Profile the XQuery code; (6) Keep a list of optimizations..."

Triple-Parity RAID and Beyond
Adam Leventhal, ACM Queue

This article examines RAID (redundant arrays of inexpensive disks), the rate of capacity growth in the hard-drive industry, and the need for triple-parity RAID as a response to diminishing reliability. "The RAID levels were codified in the late 1980s; double-parity RAID, known as RAID-6, is the current standard for high-availability, space-efficient storage. The incredible growth of hard-drive capacities, however, could impose serious limitations on the reliability even of RAID-6 systems. Recent trends in hard drives show that triple-parity RAID must soon become pervasive...

Problematically for RAID, hard-disk throughput has failed to match the exponential rate of growth. Today repairing a high-density disk drive in a RAID group can easily take more than four hours, and the problem is getting significantly more pronounced as hard-drive capacities continue to outpace their throughput. As the time required for rebuilding a disk increases, so does the likelihood of data loss...

RAID-6, double-parity RAID, was not described in Patterson, Gibson, and Katz's original 1988 paper but was added in 1993 in response to the observation that as disk arrays grow, so too do the chances of a double failure. Further, in the event of a failure under any redundancy scheme, data on all drives within that redundancy group must be successfully read in order for the data that had been on the failed drive to be reconstructed. A read failure during a rebuild would result in data loss...

Fifteen years ago, RAID-5 reached a threshold at which it no longer provided adequate protection. The answer then was RAID-6. Today RAID-6 is quickly approaching that same threshold. In about 10 years, RAID-6 will provide only the level of protection that we get from RAID-5 today. It is again time to create a new RAID level to accommodate the realities of disk reliability, capacity, and throughput merely to maintain that same level of data protection. With RAID-6 increasingly unable to meet reliability requirements, there is an impending but not yet urgent need for triple-parity RAID. The addition of another level of parity mitigates increasing RAID rebuild times and occurrences of latent data errors..."


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

Headlines

Sponsors