Cover Pages: XML Daily Newslink: Tuesday, 03 July 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:
Sun Microsystems, Inc. http://sun.com

Headlines

SOAP 1.2 Part 3: One-Way MEP
Apache Module in C for the Atom Publishing Protocol
Use JsonML to Build and Extend UI Elements
JBoss Adds Google Gadgets to Portal Software
Configuration Data Model for IPFIX and PSAMP
Accessibility of Ecma Office Open XML File Formats
WS-SecurityPolicy Version 1.2 Approved as an OASIS Standard
The Content Assembly Mechanism (CAM) and SOA Data Service Layers

Cover Pages

Major Revision of Massachusetts Enterprise Technical Reference Model (ETRM)

SOAP 1.2 Part 3: One-Way MEP
David Orchard (ed), W3C Note

Members of the W3C XML Protocol Working Group have published "SOAP 1.2 Part 3: One-Way MEP" as a Working Group Note. SOAP Version 1.2 Part 2 provides a request-response MEP and a response-only MEP. This document, the SOAP 1.2 Part 3, provides a one-way MEP. The SOAP One-way MEP defines properties for the exchange of a SOAP message. In the absence of failure in the underlying protocol, this MEP consists of zero or more SOAP messages. The scope of a one-way MEP instance is limited to transmission of messages from one sending node to zero or more receiving SOAP node(s). The ImmediateSender and ImmediateDestination properties may differ among nodes. The envelope in the InboundMessage property at each successful receiver should be identical to the envelope in the OutboundMessage at the sender. Implementations may choose to support multiple MEPs at the same time. The One-way MEP defines a set of four properties: InboundMessage, OutboundMessage, ImmediateDestination, ImmediateSender. This MEP may be extended by later specifications. Such extensions may add additional properties to the ones listed above.

See also: the W3C news item

Apache Module in C for the Atom Publishing Protocol
Tim Bray, Ongoing Blog

As summarized by Kurt Cagle: "Tim Bray recently announced his publication of a new Apache module, mod_atom, which will make it possible to use the Atom Publishing Protocol (APP) directly with the Apache HTTPD server. This is a pivotal achievement, and one that will rocket APP into daily use. APP uses Atom feed content and HTTP headers to build a publishing 'blog' system, though its uses extend considerably beyond the normal scope for blogging and could very well be a staple of most data publishing systems within the next few years." From the Ongoing Blog description: "An Apache Module provides code that gets linked into httpd, the Web server binary. There are hundreds; a few are included with the server distro, but most aren't. Code in a module doesn't have to do anything like CGI, you're just a C subroutine that gets called with a package of details about the request and the current server state. Which can save some cycles... I think that the Atom Publishing Protocol is going to be a big enough part of the Web ecosystem that Apache, as perhaps the world's single most important piece of Web infrastructure, really ought to support it. Think of it as giving PUT something useful to do. What Does it Do? It implements all of the Atom Protocol, near as I can tell. There's no database: everything is persisted in files. Since it blasts Atom Entries straight into files, it can easily (unlike most Atom protocol implementations) preserve foreign markup. It should run fine under any MPM, without concurrency issues. All the 'atom:id' values begin 'urn:uuid', so you could in principle move a whole publication from one server and directory to another. Those who have memories of me arguing bitterly against URNs in general and atom:id in particular can please restrain your snickering while I'm around. For the moment, mod_atom is just an Atom server, not a blog engine. Which is to say that it accepts and stores and updates and deletes the Atom Entries and generates feeds appropriately, but doesn't actually generate any HTML versions..."

See also: Atom references

Use JsonML to Build and Extend UI Elements
Martin Brown, IBM developerWorks

The rise of JavaScript Object Notation (JSON) has gone hand-in-hand with the rise of Asynchronous JavaScript + XML (Ajax). JavaScript Object Notation (JSON) aims to solve most of the issues with the use of XML, the parsing of that content, and it's translation into a more usable internal structure by utilizing the abilities of the JavaScript standard to exchange information. At its heart JSON is still a text format, but it is more human readable and is more compatible with how you generally create nested data objects in many languages (including Perl, PHP, Python, Java, Ruby) and that works well with the JavaScript object format (which is essentially just a nested data structure anyway). JSON is useful because it enables you to easily transmit data that can be turned back into a JavaScript object, but it still requires custom scripting to deal with that object. JsonML is an extension of JSON that enables you to map XML data using JSON type markup, and this in turn enables you to easily create XML or XHTML data based on JSON markup and to build and exchange user interface (UI) elements. JsonML melds the simplicity of the JSON markup with the DOM as the target format. You get the same benefits; the source is easily loadable and parseable by a JavaScript client (without having to worry about the DOM implementation in use). Also, because you can describe everything in the JsonML document, you have effectively embedded both the data and the markup into a single file. Because you don't need the DOM to build the output, you don't need a complex parsing process to generate the UI elements. This article shows you how to make use of this handy tool.

JBoss Adds Google Gadgets to Portal Software
Paul Krill, InfoWorld

The latest upgrade to the JBoss open source portal software integrates Google Gadgets mini-apps and makes personalizing individual portlets easier. With Google Gadgets, developers can drop Google Gadget components onto a portal. These are mini-applications that work with the Google homepage, Google Desktop, or any page on the Web. Examples of Gadgets include a calendar, a weather globe, or a media player. JBoss Portal 2.6 also adds improvements in personalization, identity management, and workflow, JBoss said. The software will serve as the foundation of the JBoss Enterprise Portal Platform. Advanced personalization in version 2.6 enables users to personalize individual portlets, including themes, layouts, and content, to suit specific roles. The use of jBPM (Business Process Management) in the product provides content management approval workflow in a configurable process. Prebuilt LDAP integration is featured with servers supported, including Red Hat Director Server, OpenDS, and OpenLDAP. JBoss Portal 2.6 also features integration with the Ajax4jsf and RichFaces development frameworks. Extended support for the Web Services for Remote Portlets specification also is featured in version 2.6 with implicit cloning capabilities added. Cloning allows for deploying one instance of a portlet and reusing it with a different configuration. LGPL.

See also: InternetNews.com

Configuration Data Model for IPFIX and PSAMP
Gerhard Muenz and Benoit Claise (eds), IETF Internet Draft

This document specifies a data model for the configuration of Metering Processes, Exporting Processes, and Collecting Processes for IPFIX and PSAMP compliant monitoring devices. An implementation of the data model in Extensible Markup Language (XML) is defined using XML Schema language. IPFIX and PSAMP compliant monitoring devices (routers, switches, monitoring probes, mediators, collectors etc.) offer various configuration possibilities that allow adapting network monitoring to the goals and purposes of the application, e.g. accounting and charging, traffic analysis, performance monitoring, security monitoring etc. The use of a common device-independent configuration data model for IPFIX and PSAMP compliant monitoring devices facilitates network management and configuration, especially if monitoring devices of different implementers and/or manufacturers are deployed simultaneously. The purpose of this document is the specification of such a device-independent configuration data model that covers the commonly available configuration parameters of Metering Processes, Exporting Processes, and Collecting Processes. The specified data model implemented in Extensible Markup Language (XML) allows extending it easily with additional device-specific parameters. Furthermore, optional parameters as well as parameters not supported by a particular monitoring device implementation can be simply omitted. Any restrictions and extensions of the configuration data model should be known to the network management system in order to avoid sending unsupported configuration data to the monitoring device. Note that the communication of monitoring device capabilities to the network management system is currently out of scope of this document. There are various candidate protocols, like the Network Configuration Protocol (Netconf) or the Simple Object Access Protocol (SOAP), that are suitable for transferring XML data from a network management system to a monitoring device. However, the configuration data model specified here is not specific to any of these.

See also: PSAMP Information Model

Accessibility of Ecma Office Open XML File Formats
Staff, Microsoft Community Contribution

"Open XML Formats support accessibility in a number of ways. In explaining this support to its customers, partners and assistive technology vendors, Microsoft has created a preliminary draft report describing how Open XML compares to W3C Web Content Accessibility Guidelines and W3C XML Accessibility guidelines. Microsoft is donating this project to the OpenXMLDeveloper.org community. By doing so, Microsoft hopes to raise the level of awareness and education of the accessibility support in the existing standard, as well as evaluate Open XML using other accessibility criteria. This project is open for comment and discussion. The attached dowload contains the report in DOCX, PDF, and HTML formats." From the Introduction: "The accessibility support in Open XML is designed to enable software applications to correctly process and present information to users with assistive technology requirements. Because the actual software products in use play such an important role in enabling assistive technology, it is important that a document format support the needs of this user community. This white paper describes support of accessibility for the Open XML formats. This discussion covers areas of extensibility, modularization, expressivities, performance, and reuse of standards, programmability and ease of use. The adoption of Accessibility in the Open XML standard will help many technology providers carry forward the information stored in billions of existing documents AND preserve the information in that document intended to enable accessibility. The support is initiated based on the support provided by Open XML formats for check points defined in Web Content Accessibility Guidelines 1.0 and XML Accessibility Guidelines for accessibility. Each of check points in the guideline documents have the priority level defined by working group based on the impact on accessibility...."

See also: the ZIP archive

WS-SecurityPolicy Version 1.2 Approved as an OASIS Standard
Staff, OASIS Announcement

The Committee Specification for "WS-SecurityPolicy Version 1.2" balloted for approved has been ratified as an OASIS Standard. The specification was produced by members of the OASIS Web Services Secure Exchange (WS-SX) Technical Committee under TC Co-chairs Kelvin Lawrence (IBM) and and Chris Kaler (Microsoft). WS-Policy defines a framework for allowing web services to express their constraints and requirements. Such constraints and requirements are expressed as policy assertions. This document (WS-SecurityPolicy) defines a set of security policy assertions for use with the WS-Policy framework with respect to security features provided in WSS: SOAP Message Security, WS-Trust, and WS-SecureConversation. The assertions defined within this specification have been designed to work independently of a specific version of WS-Policy. At the time of the publication of this specification the versions of WS-Policy known to correctly compose with this specification are WS-Policy 1.2 and 1.5. Within this specification the use of the namespace prefix 'wsp' refers generically to the WS-Policy namespace, not a specific version. This document takes the approach of defining a base set of assertions that describe how messages are to be secured. Flexibility with respect to token types, cryptographic algorithms and mechanisms used, including using transport level security is part of the design and allows for evolution over time. The intent is to provide enough information for compatibility and interoperability to be determined by web service participants along with all information necessary to actually enable a participant to engage in a secure exchange of messages.

See also: the announcement

The Content Assembly Mechanism (CAM) and SOA Data Service Layers
David RR Webber, The SOA Magazine

As use of SOA systems expands the effort needed for integration of content transaction exchanges will become increasingly an inhibiting factor comparable to how legacy EDI systems reached a level of saturation in their traditional deployment niche. The danger is that the very success of SOA-enabled interfaces can threaten to overwhelm an organization's ability to operate them, due to the fact that the cost of supporting and maintaining these interfaces can overshadow their potential return on investment. The new OASIS Content Assembly Mechanism (CAM) templates standard provides significant technology advances that reduce and spread out data service integration burdens. Furthermore, by providing an open public standard the CAM approach enables industry domains and e-government initiatives to freely share formal business rule sets and transaction use patterns directly in machine processable formats. For the business data analysts involved in SOA implementations the CAM documentation formats allow direct agreement between stakeholders on business rule details that are then directly applied in the SOA data services layer without requiring re-programming. Achieving a reduction in complexity and consistency in representation remains a continuing business challenge. In this article I explore the progress to date achieved with CAM and look at opportunities and scope for facilitating SOA data services and the various deployment models available.

See also: CAM Version 1.1

Selected from the Cover Pages, by Robin Cover

Major Revision of Massachusetts Enterprise Technical Reference Model (ETRM)

The U.S. Commonwealth of Massachusetts Information Technology Division (ITD) announced a new major release of the Enterprise Technical Reference Model (ETRM). The ETRM Version 4.0 Introduction identifies four additional and updated specifications now included in the 'Summary of Technology Specifications' table. Newly added specifications include "WS-I Basic Security Profile v. 1.0" and "Ecma 376 - Office Open XML Formats (Open XML)". Specification updates are listed for "OASIS Open Document Format for Office Applications (OpenDocument) v. 1.1" and W3C "XPath v. 2.0". The ITD Enterprise Technical Reference Model (ETRM) "provides an architectural framework used to identify the standards, specifications and technologies that support the Commonwealth's computing environment. The ETRM uses the concepts of Domains, Disciplines, Technology Areas and Technology Specifications to define the enterprise architecture." The addition of "Ecma-376 Office Open XML File Formats (Open XML)" as an "Open Format" represents a significant change in ETRM Version 4.0. The Commonwealth of Massachusetts "defines open formats as specifications for data file formats that are based on an underlying open standard, developed by an open community, affirmed and maintained by a standards body, and are fully documented and publicly available." ETRM now classifies four (4) formats as "Open Formats": (1) OASIS Open Document Format For Office Applications (OpenDocument) v. 1.1; (2) Ecma-376 Office Open XML Formats (Open XML); (3) Hypertext Document Format v. 4.01; (4) Plain Text Format.


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

Headlines

Cover Pages

Sponsors