Cover Pages: XML Daily Newslink: Tuesday, 16 March 2010

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:
Oracle Corporation http://www.oracle.com

Headlines

W3C XML Security Working Group Releases Four Working Drafts for Review
Early Draft Review for JSR-310 Specification: Date and Time API
OASIS SCA-C-C++ Technical Committee Publishes Two Public Review Drafts
IESG Issues Last Call Review for MODS/MADS/METS/MARCXML/SRU Media Types
Open Source of ebMS V3 Message Handler and AS4 Profile on Sourceforge
HTML5, Hardware Accelerated: First IE9 Platform Preview Available
New Release of Oxygen XML Editor and Oxygen XML Author Supports DITA
What Standardization Will Mean For Ruby

W3C XML Security Working Group Releases Four Working Drafts for Review
Staff, W3C Announcement

Members of the W3C XML Security Working Group have published four Working Draft specifications for public review. This WG, along with the W3C Web Security Context Working Group, is part of the W3C XML Security Activity, and is chartered to to take the next step in developing the XML security specifications.

XML Encryption Syntax and Processing Version 1.1 specifies "a process for encrypting data and representing the result in XML. The data may be in a variety of formats, including octet streams and other unstructured data, or structure data formats such as XML documents, an XML element, or XML element content. The result of encrypting data is an XML Encryption element which contains or references the cipher data"

XML Security Algorithm Cross-Reference is a W3C Note which "summarizes XML Security algorithm URI identifiers and the specifications associated with them. The various XML Security specifications have defined a number of algorithms of various types, while allowing and expecting additional algorithms to be defined later. Over time, these identifiers have been defined in a number of different specifications, including XML Signature, XML Encryption, RFCs and elsewhere. This makes it difficult for users of the XML Security specifications to know whether and where a URI for an algorithm of interest has been defined, and can lead to the use of incorrect URIs. The purpose of this Note is to collect the various known URIs at the time of its publication and indicate the specifications in which they are defined in order to avoid confusion and errors... The note indicates explicitly whether an algorithm is mandatory or recommended in other specifications. If nothing is said, then readers should assume that support for the algorithms given is optional."

The XML Security Generic Hybrid Ciphers Working Draft "augments XML Encryption Version 1.1 by defining algorithms, XML types and elements necessary to enable use of generic hybrid ciphers in XML Security applications. Generic hybrid ciphers allow for a consistent treatment of asymmetric ciphers when encrypting data and consist of a key encapsulation algorithm with associated parameters and a data encapsulation algorithm with associated parameters." Fourth, XML Security RELAX NG Schemas serves to publish RELAX NG schemas for XML Security specifications, including XML Signature 1.1 and XML Signature Properties.

Early Draft Review for JSR-310 Specification: Date and Time API
Stephen Colebourne, Michael Nascimento Santos (et al, eds), JSR Draft

Project editors for Java Specification Request 310: Date and Time API have published an Early Draft Review (EDR) to to gain feedback on an early version of the JSR. The contents of the EDR are the prose specification and the javadoc. According to the original published Request, JSR 310 "will provide a new and improved date and time API for Java. The main goal is to build upon the lessons learned from the first two APIs (Date and Calendar) in Java SE, providing a more advanced and comprehensive model for date and time manipulation.

The new API will be targeted at all applications needing a data model for dates and times. This model will go beyond classes to replace Date and Calendar, to include representations of date without time, time without date, durations and intervals. This will raise the quality of application code. For example, instead of using an int to store a duration, and javadoc to describe it as being a number of days, the date and time model will provide a class defining it unambiguously. The new API will also tackle related date and time issues. These include formatting and parsing, taking into account the ISO8601 standard and its implementations, such as XML. In addition, the areas of serialization and persistence will be considered... In this specification model, dates and times are separated into two basic use cases: machine-scale and human-scale. Machine-scale time represents the passage of time using a single, continually incrementing number. The rules that determine how the scale is measured and communicated are typically defined by international scientific standards organisations. Human-scale time represents the passage of time using a number of named fields, such as year, month, day, hour, minute and second. The rules that determine how the fields work together are defined in a calendar system...

From the specification introduction: "Many Java applications require logic to store and manipulate dates and times. At present, Java SE provides a number of disparate APIs for this purpose, including Date, Calendar, SQL Date/Time/Timestamp and XML Duration/XMLGregorianCalendar. Unfortunately, these APIs are not all particularly well-designed and they do not cover many use cases needed by developers. As an example, Java developers currently have no standard Java SE class to represent the concept of a date without a time, a time without a date or a duration. The result of these missing features has been widespread abuse of the facilities which are provided, such as using the Date or Calendar class with the time set to midnight to represent a date without a time. Such an approach is very error-prone - there are certain time zones where midnight doesn't exist once a year due to the daylight saving time cutover. JSR-310 tackles this by providing a comprehensive set of date and time classes suitable for Java SE today. The specification includes: Date and Time; Date without Time; Time without Date; Offset from UTC; Time Zone; Durations; Periods; Formatting and Parsing; A selection of calendar systems...

Design Goals for JSR-310: (1) Immutable - The JSR-310 classes should be immutable wherever possible. Experience over time has shown that APIs at this level should consist of simple immutable objects. These are simple to use, can be easily shared, are inherently thread-safe, friendly to the garbage collector and tend to have fewer bugs due to the limited state-space. (2) Fluent API - The API strives to be fluent within the standard patterns of Java SE. A fluent API has methods that are easy to read and understand, specifically when chained together. The key goal here is to simplify the use and enhance the readability of the API. (3) Clear, explicit and expected - Each method in the API should be well-defined and clear in what it does. This isn't just a question of good javadoc, but also of ensuring that the method can be called in isolation successfully and meaningfully. (4) Extensible - The API should be extensible in well defined ways by application developers, not just JSR authors. The reasoning is simple - there are just far too many weird and wonderful ways to manipulate time. A JSR cannot capture all of them, but an extensible JSR design can allow for them to be added as required by application developers or open source projects..."

OASIS SCA-C-C++ Technical Committee Publishes Two Public Review Drafts
Bryan Aupperle, David Haney, Pete Robbins (eds), OASIS Review Drafts

Members of the OASIS Service Component Architecture / C and C++ (SCA-C-C++) Technical Committee have released two Committee Drafts for public review through March 25, 2010. This TC is part of the OASIS Open Composite Services Architecture (Open CSA) Member Section that advances open standards that simplify SOA application development. Open CSA brings together vendors and users from around the world to collaborate on standard ways to unify services regardless of programming language or deployment platform. Open CSA promotes the further development and adoption of the Service Component Architecture (SCA) and Service Data Objects (SDO) families of specifications. 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.

Service Component Architecture Client and Implementation Model for C++ Specification Version 1.1 describes "the SCA Client and Implementation Model for the C++ programming language. The SCA C++ implementation model describes how to implement SCA components in C++. A component implementation itself can also be a client to other services provided by other components or external services. The document describes how a C++ implemented component gets access to services and calls their operations. Thisdocument also explains how non-SCA C++ components can be clients to services provided by other components or external services. The document shows how those non-SCA C++ component implementations access services and call their operations."

Service Component Architecture Client and Implementation Model for C Specification Version 1.1 describes "the SCA Client and Implementation Model for the C programming language. The SCA C implementation model describes how to implement SCA components in C. A component implementation itself can also be a client to other services provided by other components or external services. The document describes how a component implemented in C gets access to services and calls their operations. The document also explains how non-SCA C components can be clients to services provided by other components or external services. The document shows how those non-SCA C component implementations access services and call their operations."

The OASIS SCA-C-C++ TC is developing "the C and C++ programming model for clients and component implementations using the Service Component Architectire (SCA). SCA defines a model for the creation of business solutions using a Service-Oriented Architecture, based on the concept of Service Components which offer services and which make references to other services. SCA models business solutions as compositions of groups of service components, wired together in a configuration that satisfies the business goals. SCA applies aspects such as communication methods and policies for infrastructure capabilities such as security and transactions through metadata attached to the compositions."

IESG Issues Last Call Review for MODS/MADS/METS/MARCXML/SRU Media Types
Ray Denenberg (ed), IETF Internet Draft

The Internet Engineering Steering Group (IESG) has received a request from an individual submitter the following Standards Track I-D as an IETF Proposed Standard: The Media Types application/mods+xml, application/mads+xml, application/mets+xml, application/marcxml+xml, application/sru+xml. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action; please send substantive comments to the IETF lists by 2010-04-12.

This document "specifies Media Types for the following formats: MODS (Metadata Object Description Schema), MADS (Metadata Authority Description Schema), METS (Metadata Encoding and Transmission Standard), MARCXML (MARC21 XML Schema), and the SRU (Search/Retrieve via URL Response Format) Protocol response XML schema. These are all XML schemas providing representations of various forms of information including metadata and search results.

The U.S. Library of Congress, on behalf of and in collaboration with various components of the metadata and information retrieval community, has issued specifications which define formats for representation of various forms of information including metadata and search results. This memo provides information about the Media Types associated with several of these formats, all of which are XML schemas. (1) 'MODS: Metadata Object Description Schema' is an XML schema for a bibliographic element set that may be used for a variety of purposes, and particularly for library applications. (2) 'MADS: Metadata Authority Description Schema' is an XML schema for an authority element set used to provide metadata about agents (people, organizations), events, and terms (topics, geographics, genres, etc.). It is a companion to the MODS Schema. (3) 'METS: Metadata Encoding and Transmission Standard" defines an XML schema for encoding descriptive, administrative, and structural metadata regarding objects within a digital library.

(4) 'MARCXML MARC21 XML Schema' is an XML schema for the direct XML representation of the MARC format (for which there already exists a media type, application/marc; By 'direct XML representation'is is meant that it encodes the actual MARC data within XML... (5) 'SRU: Search/ Retrieve via URL Response Format' provides an XML schema for the SRU response. SRU is a protocol, and the media type 'sru+xml' pertains specifically to the default SRU response. the SRU response may be supplied in any of a number of suitable schemas, RSS, ATOM, for example, and the client identifies the desired format in the request, hence the need for a media type. This mechanism will be introduced in SRU 2.0; in previous versions (that is, all versions to date; 2.0 is in development) all responses are supplied in the existing default format, so no media type was necessary. SRU 2.0 is being developed within OASIS.

Open Source of ebMS V3 Message Handler and AS4 Profile on Sourceforge
Jacques Durand, ebXML.org Posting

Holodeck is an open source version of ebXML Messaging Version 3 and its AS4 profile is now available on Sourceforge with online documentation. The ebXML Messaging V3 specification defines a communications-protocol neutral method for exchanging electronic business messages. It defines specific Web Services-based enveloping constructs supporting reliable, secure delivery of business information. Furthermore, the specification defines a flexible enveloping technique, permitting messages to contain payloads of any format type...

The OASIS specification AS4 Profile of ebMS V3 abstract: "While ebMS 3.0 represents a leap forward in reducing the complexity of Web Services B2B messaging, the specification still contains numerous options and comprehensive alternatives for addressing a variety of scenarios for exchanging data over a Web Services platform. The AS4 profile of the ebMS 3.0 specification has been developed in order to bring continuity to the principles and simplicity that made AS2 successful, while adding better compliance to Web services standards, and features such as message pulling capability and a built-in Receipt mechanism. Using ebMS 3.0 as a base, a subset of functionality is defined along with implementation guidelines adopted based on the 'just-enough' design principles and AS2 functional requirements to trim down ebMS 3.0 into a more simplified and AS2-like specification for Web Services B2B messaging. This document defines the AS4 profile as a combination of a conformance profile that concerns an implementation capability, and of a usage profile that concerns how to use this implementation. A couple of variants are defined for the AS4 conformance profile—the AS4 ebHandler profile and the AS4 Light Client profile—that reflect different endpoint capabilities."

Holodeck's primary goal is to provide an Open-Source product for B2B messaging based on ebXML Messaging version 3 that can be used by ebXML communities as well as WebServices communities. Because ebXML Messaging version 3 is compatible with webservices, Holodeck provides an integration of ebXML, webservices and AS4 in one package. Holodeck can be used in the following scenarios: (1) Pure ebXML messaging in the B2B or within different departments of the same company. (2) Messaging Gateway to an ESB. The ESB providing an integration within a company, while Holodeck playing the gateway to communicate with the external world via messaging. (3) An environment where there is a need for both Webservice consumption and heavy B2B messaging where web services fail...

Holodeck comes with a scalable architecture: datastore for messages (JDO by default, a MySQL pre-configured option, and interfaces to other databases), and streaming for large messages (based on Axis2 streaming). The project is funded and maintained by Fujitsu America, Inc. This package comes with a "no coding necessary" out-of-the-box experience and tutorials, allowing you to deploy and test without having to write code up-front, using a directory system as application layer substitute to store as files elements of messages to be sent, and to receive them. Developers can download binaries and source code, and get a fresh copy directly from "Subversion" versioning system...

HTML5, Hardware Accelerated: First IE9 Platform Preview Available
Dean Hachamovitch, Windows Internet Explorer Weblog

At the Las Vegas MIX10 Conference, Microsoft Internet Explorer developers demonstrated "how the standard web patterns that developers already know and use broadly run better by taking advantage of PC hardware through IE9 on Windows." A blog article by Dean Hachamovitch provides an overview of what we showed, "across performance, standards, hardware-accelerated HTML5 graphics, and the availability of the IE9 Platform Preview for developers...

First, we showed IE9's new script engine, internally known as 'Chakra,' and the progress we've made on an industry benchmark for JavaScript performance... We showed our progress in making the same standards-based HTML, script, and formatting markup work across different browsers. We shared the data and framework that informed our approach, and demonstrated better support for several standards: HTML5, DOM, and CSS3. We showed IE9's latest Acid3 score (55); as we make progress on the industry goal of having the same markup that developers actually use working across browsers, our Acid3 score will continue to go up...

In several demonstrations, we showed the significant performance gains that graphically rich, interactive web pages enjoy when a browser takes full advantage of the PC's hardware capabilities through the operating system. The same HTML, script, and CSS markup work across several different browsers; the pages just run significantly faster in IE9 because of hardware-accelerated graphics. IE9 is also the first browser to provide hardware-accelerated SVG support...The goal of standards and interoperability is that the same HTML, script, and formatting markup work the same across different browsers. Eliminating the need for different code paths for different browsers benefits everyone, and creates more opportunity for developers to innovate.

The main technologies to call out here broadly are HTML5, CSS3, DOM, and SVG. The IE9 test drive site has more specifics and samples. At this time, we're looking for developer feedback on our implementation of HTML5's parsing rules, Selection APIs, XHTML support, and inline SVG. Within CSS3, we're looking for developer feedback on IE9's support for Selectors, Namespaces, Colors, Values, Backgrounds and Borders, and Fonts. Within DOM, we're looking for developer feedback on IE9's support for Core, Events, Style, and Range... As IE makes more progress on the industry goal of 'same markup' for standards and parts of standards that developers actually use, the Acid3 score will continue to go up as a result. A key part of our approach to web standards is the development of an industry standard test suite. Today, Microsoft has submitted over 100 additional tests of HTML5, CSS3, DOM, and SVG to the W3C..."

New Release of Oxygen XML Editor and Oxygen XML Author Supports DITA
Staff, Syncro Soft Announcement

Developers of the Oxygen XML Editor and Author toolsuite have announced the immediate availability of version 11.2 of the XML Editor and XML Author containing a comprehensive set of tools supporting all the XML related technologies. Oxygen combines content author features like the CSS driven Visual XML editor with a fully featured XML development environment. It has ready to use support for the main document frameworks DITA, DocBook, TEI and XHTML and also includes support for all XML Schema languages, XSLT/XQuery Debuggers, WSDL analyzer, XML Databases, XML Diff and Merge, Subversion client and more.

New features in version 11.2: Version 11.2 of Oxygen XML Editor improves the XML authoring, the XML development tools, the support for large documents and the SVN Client. The visual XML editing (Author mode) is available now as a separate component that can be integrated in Java applications or, as an Applet, in Web applications. A sample Web application showing the Author component in the browser, as an Applet, editing DITA documents is available...

Other XML Author improvements include support for preserving the formatting for unchanged elements and an updated Author API containing a number of new extensions that allow customizing the Outline, the Breadcrumb and the Status Bar. The XSLT Debugger provides more flexibility and it is the first debugger that can step inside XPath 2.0 expressions. The Saxon 9 EE bundled with Oxygen can be used to run XQuery 1.1 transformations. The XProc support was aligned with the recent update as W3C Proposed Recommendation and includes the latest Calabash XProc processor.

In 'Author for DITA' there is support for Reusable Components: A fragment of a topic can be extracted in a separate file for reuse in different topics. The component can be reused by inserting an element with a conref attribute where the content of the component is needed. This works without any additional configuration and supports any DITA specialization. Similarly, there's support for Content References Management: The DITA framework includes actions for adding, editing and removing a content reference (conref, conkeyref, conrefend attributes) to/from an existing element... A new schema caching mechanism allows to quickly open large DITA Maps and their referred topics..."

What Standardization Will Mean For Ruby
Mirko Stocker, InfoQueue

Ruby's inventor Matz announced plans to standardize Ruby in order to "improve the compatibility between different Ruby implementations [..] and to ease Ruby's way into the Japanese government". The first proposal for standardization will be to the Japanese Industrial Standards Committee and in a further step to the ISO, to become an international standard. For now, a first draft (that weighs in at over 300 pages) and official announcement are available. Alternatively, there's a wiki under development to make the standard available in HTML format.

A very different approach to unite Ruby implementations is the RubySpec project—a community driven effort to build an executable specification. RubySpec is an offspring of the Rubinius project... [But] What do our readers think: will it be easier to introduce Ruby in their organizations if there's an ISO standard behind it?"

According to RubySpec lead Brian Ford: "I think the ISO Standardization effort is very important for Ruby, both for the language and for the community, which in my mind includes the Ruby programmers, people who use software written in Ruby, and the increasing number of businesses based on or using software written in Ruby. The Standardization document and RubySpec are complementary in my view. The document places primary importance on describing Ruby in prose with appropriate formatting formalities. The document envisions essentially one definition of Ruby.

RubySpec, in contrast, places primary importance on code that demonstrates the behavior of Ruby. However, RubySpec also emphasizes describing Ruby in prose as an essential element of the executable specification and is the reason we use RSpec-compatible syntax. RubySpec also attempts to capture the behavior of the union of all Ruby implementations. It provides execution guards that document the specs for differences between implementations. For example, not all platforms used to implement Ruby support forking a process. So the specs have guards for which implementations provide that feature... This illustrates an important difference between the ISO Standardization document and RubySpec. The ISO document can simply state that a particular aspect of the language is "implementation defined" and provide no further guidance. Unfortunately, implementing such a standard can be difficult, as we have seen with the confusion caused by various browser vendors attempting to implement CSS. RubySpec attempts to squeeze the total number of unspecified Ruby behaviors to the smallest size possible..."

See also: the Ruby Standard Wiki


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

Headlines

Sponsors