Cover Pages: XML Daily Newslink: Tuesday, 27 January 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:
IBM Corporation http://www.ibm.com

Headlines

Apache Software Foundation Announces Release of Cocoon Version 3
Lotus Symphony: Looking to Go Beyond Playing Catch Up
Integration Between XML Forms Generator and Data Studio, Part 2: DB2 pureXML Support in XFG
CMIS Apache Jackrabbit Sandbox: F2F Presentation Transcript
IMI TC Contribution: Retrieving Information Card Metadata via HTTPS GET
Invoke RESTful Web Services from JavaFX
Conference Event Package Data Format Extension for Centralized Conferencing (XCON)

Apache Software Foundation Announces Release of Cocoon Version 3
Reinhard Pötz, Apache Project Announcement

On behalf of the Apache Cocoon Development Community, PMC member and Apache Cocoon Committer Reinhard Pötz announced the release of Cocoon 3.0.0-alpha-1. "Apache Cocoon 3 is a major rewrite of Cocoon 2.2. Like Cocoon 2 it is based around the concept of pipelines and sitemaps and it is very similar to Cocoon 2.2 in many respects but is slimmed down and designed to be easily used with Java code; thus, no frameworks are required. On top of this, Cocoon 3 has the goal of becoming the best available platform for RESTful webservices and web applications. "Apache Cocoon, usually just called Cocoon, is a web application framework built around the concepts of pipeline, separation of concerns and component- based web development. The framework focuses on XML and XSLT publishing and is built using the Java programming language. The flexibility afforded by relying heavily on XML allows rapid content publishing in a variety of formats including HTML, PDF, and WML. The content management systems Apache Lenya and Daisy have been created on top of the framework. Cocoon is also commonly used as a data warehousing ETL tool or as middleware for transporting data between systems..." [Wikipedia] Cocoon Version 3 consists of three layers. Each of this layers is packaged as separate module: (1) cocoon-pipeline; (2) cocoon-sitemap; (3) cocoon-servlet. Additionally there are more optional modules (cocoon-stringtemplate, cocoon-controller, cocoon-rest). The idea behind using a pipeline is that the content of the pipeline (e.g., SAX events) is streamed without any necessary serialization or deserialization steps between the components. The Cocoon Pipeline module doesn't have any third-party dependencies. Currently it provides three pipeline implementations: noncaching, caching, and async-caching. This module provides a basic set of SAX components: FileGenerator; XSLTTransformer; XMLSerializer; IncludeTransformer; CleaningTransformer; FileReader; StringGenerator... A sitemap connects a request (not necessarily a servlet request) with a pipeline. The Cocoon Servlet module provides a servlet that connects an HTTP request with a sitemap. It works smoothly within the Servlet-Service framework. The Servlet-Service framework enables the inter-sitemap communication and provides polomorphistic features, e.g., one sitemap can extend another one which allows e.g. the implementation of fallback solutions...

Lotus Symphony: Looking to Go Beyond Playing Catch Up
Guy Creese, Blog

At the moment, Symphony acts as a wannabe to Microsoft Office, with a few things missing, such as VB Macros (that feature is coming). If Symphony were just that, it wouldn't be that interesting—true, it could save you licensing fees compared to Office, but that would be all it does: it would improve the bottom line but not offer increased productivity for information workers. However, IBM Lotus is becoming a bit more outspoken about their future plans. On slide #5 of the IBM Lotus Symphony Overview (presentation ID506), the company portrayed a pyramid with five tiers... The interesting one is number five ('Beyond Office: Breakthrough document manipulation experience'): Beyond Office is the idea that Symphony should become part of an ecosystem that makes composite documents, similar to what the DITA standard allows for technical documentation. And guess what—IBM is the company that pioneered DITA. So given the company's DITA heritage and IBM Lotus' declared strategic plan, over the next several years Symphony should become a much more capable, interesting, and productivity enhancing product...

See also: DITA references

Integration Between XML Forms Generator and Data Studio, Part 2: DB2 pureXML Support in XFG
Xiao Feng Zhao, Qiang Wang, Susan Malaika, (et al.); IBM developerWorks

Gone are the days of storing XML data as a CLOB or shredding to relational tables. The pureXML feature of DB2 9 has revolutionized support for XML data—handling XML as a new data type that is stored in a natural hierarchy—as different from relational data. pureXML's seamless integration of XML with relational data speeds application development, improves search performance with highly optimized XML indexes, and is flexible because you can use both SQL and XQuery to query XML data. XML data, stored in pureXML, can be exposed as Web Services through the Data Web Service mechanism. With the pureXML support in XML Forms Generator (XFG), you can visualize pureXML into an XHTML-based XForm for users. Also, XFG can retrieve the registered related XML Schemas of pureXML instances and generate type information and validation constraints into the target pureXML XHTML/XForm. So pureXML support in XFG makes it easy to build forms interfaces for XML instances stored in pureXML. In this article, the authors briefly described the DB2 pureXML support in XFG. With the pureXML support in XML Forms Generator (XFG), you can visualize pureXML into an XHTML-based XForm for users. In addition, you can rely on XFG to retrieve the registered related XML Schemas of pureXML instances and generate type information. And the validation constraints can be fetched and added into the target pureXML XHTML/XForms. Obviously the pureXML support in XFG makes it easy to build forms interfaces for XML instances stored in pureXML. In this article series, they introduce XForms, XFG, Data Studio, Web services, and the pureXML feature support. Through these two articles, you can easily start to use XFG to generate functional XHTML/XForms UI for the backend Data Services to build a complete data service solution.

CMIS Apache Jackrabbit Sandbox: F2F Presentation Transcript
David Nuescheler, OASIS TC Meeting Presentation

From the CMIS F2F Meeting, CMIS Implementations Show and Tell, 26-January-2009, Redmond, WA, USA: "To facilitate the conversation around the CMIS sandbox architecture and goals, I quickly put together a little bit of documentation from my perspective and dumped it on the wiki as a starting point. As mentioned before, everybody is invited to participate in the Apache jackrabbit project. Prose from the Wiki: "The CMIS Sandbox at Jackrabbit Based on interest from various Apache Communities the CMIS Sandbox is hosted by the Apache Jackrabbit project and is open to all committers of the ASF. Sumamrizing conversations on the dev mailing list the goal of this effort would be to build a freely available implementation and client of the CMIS specification as it grows. While the CMIS specification is still under development the early implementation will allow to give feedback to the Technical Committee at OASIS to modify and improve the specification. The implementation should not need any Jackrabbit (Content Repository) specific dependencies but should be as portable and reusable for other implementations as possible... [As shown in the diagrams]: "The API represents the Java Language Bindings of the CMIS Model and therefore is used to implement both the CMIS client (that exposes the API) but also the server that allows for plug-able implementation of that... Proposed Server Architecture: The CMIS Server is architected in a fashion that offers a Layered approach. The AtomPub and SOAP bindings are separated by the API. This allows to use both protocol implementations while just having to implement the API on any particular proprietary or standard based server. In Jackrabbit the implementation of the API then will use a standards based JCR binding to avoid and Jackrabbit specific bindings and hence allows to be run on any third party JCR implementation... Proposed Client Architecture: To provide a general purpose CMIS Java client it is important of course provide language bindings of the CMIS Model and then implement the two protocols proposed by CMIS. This will not only be used by Java Application Developers that want to consume CMIS but also can serve as an initial test suite to test any servers interoperability..."

IMI TC Contribution: Retrieving Information Card Metadata via HTTPS GET
Mike Jones, Microsoft Contribution to OASIS IMI TC

The OASIS Identity Metasystem Interoperability (IMI) Technical Committee was chartered "to increase the quality and number of interoperable implementations of Information Cards and associated identity system components to enable the Identity Metasystem. In the Identity Metasystem, identities are represented to users as 'Information Cards'. Information Cards enable users to manage their digital identities from different identity providers and employ them in various contexts to access online services. Information Cards have a number of characteristics that help to improve user privacy and security when accessing online services..." On January 26, 2009, TC Member (and Secretary) Michael Jones announced a new contribution entitled "Retrieving Information Card Metadata via HTTPS GET," originally created in October 2008. This document describes a behavior of CardSpace that was not initially presented in the July 2008 contribution, "Identity Selector Interoperability Profile V1.5 (ISIP)" -- the ability to retrieve metadata via HTTPS GET, rather than WS-MetadataExchange. "This actually parallels WS-Federation, where Section 3.2 describes the ability to retrieve metadata in both ways as well." From the document Abstract: "The Identity Metasystem allows users to manage their Digital Identities from various Identity Providers and employ them in different contexts where they are accepted to access online services. In the Identity Metasystem, identities are represented to users as 'Information Cards'. This document supplements the information provided in three other Identity Selector Interoperability Profile references: "ISIP." which provides the normative schema definitions and behaviors for Information Cards and the interoperable Identity Selectors that use them; "ISIP Guide," which provides a non-normative description of the overall Information Card Model; and "ISIP Web Guide," which describes how Information Cards can be used within applications hosted on web sites and accessed through web browsers. This document describes an additional mechanism that can be employed by software implementing the Information Card Model to communicate Information Card Metadata: HTTPS GET. [...] Retrieving Identity Provider STS Metadata via HTTPS GET: Section 4.1.1.2 of the ISIP specification states that 'An Identity Selector MAY retrieve the Security Policy it will use to communicate with the IP/STS from that metadata location using the mechanism specified in WS-MetadataExchange'. [We here] describe another possible mechanism: retrieving the metadata document directly from the advertised metadata location using HTTPS GET. Identity Providers MAY publish metadata for Information Cards as WSDL documents that can be retrieved by Identity Selectors via HTTPS GET operations on URLs using the HTTPS scheme. And endpoint's metadata URL is communicated to Identity Selectors in a token service 'wsx:MetadataReference' element in an Information Card using exactly the same syntax as when MEX is employed to retrieve the metadata. No change occurs in the card. The metadata documents published via HTTPS GET SHOULD contain the WSDL for the endpoint as the top-level element of the document without any SOAP or MEX elements enclosing it. Identity Providers MAY publish endpoint metadata via both the HTTPS GET and MEX methods at the same metadata location. If they publish the metadata via multiple mechanisms, the metadata delivered via both mechanisms SHOULD be the same. Likewise, Identity Selectors MAY attempt to retrieve metadata via multiple mechanisms, either in sequence or in parallel...

See also: the IMI TC posting (source)

Invoke RESTful Web Services from JavaFX
Edmon Begoli, DevX.com

JavaFX, a new Sun Microsystems product family (including a scripting language, JavaFX Script), is optimized for implementing rich Internet applications for desktop and mobile devices. It comes bundled with the latest editions of the Java SE Runtime Environment (JRE) and Development Kit (JDK), and it provides its own API. Although JavaFX Script uses syntax that somewhat resembles Java and JavaScript, it is important to understand how JavaFX differs from Java. One area in particular where this understanding would be helpful for Java developers who are just beginning to explore JavaFX is RESTful web services invocation. This 10-Minute Solution demonstrates how to invoke RESTful web services from JavaFX, and how to process the results. In an example, we show how to call a RESTful web service that provides information about airport departures and arrivals to a JavaFX front end... [Related article, by Jim Rapoza, in eWEEK: "Application Development Slideshow: eWEEK Labs Walk-Through: Sun Microsystems JavaFX"—With JavaFX 1.0, Sun hopes to entice Web and graphics professionals and bring Java fully into the modern world of rich Internet applications, a space currently dominated by Adobe AIR and Microsoft's Silverlight platform..."]

See also: eWEEK on JavaFX

Conference Event Package Data Format Extension for Centralized Conferencing (XCON)
Gonzalo Camarillo, Srivatsa Srinivasan (et al.); IETF Internet Draft

Members of the IETF Centralized Conferencing (XCON) Working Group produced an updated I-D describing a Conference Event Package Data Format Extension. The working group was chartered to develop a standardized suite of protocols for tightly-coupled multimedia conferences, where strong security and authorization requirements are integral to the solution The IETF "Framework for Centralized Conferencing" RFC for XCON defines a notification service that provides updates about a conference instance's state to authorized parties using a notification protocol. In addition to specifying the SIP event package for conference state, RFC 4575 specifies a data format to be used with the event package. The XCON data model extends that format with new elements and attributes so that the extended format supports more functionality (e.g., floor control). The notification protocol specified in this document supports all the data defined in the XCON data model, plus a partial notification mechanism based on XML patch operations... This document ("Conference Event Package Data Format Extension for Centralized Conferencing") specifies the notification mechanism for XCON (centralized conferencing). This mechanism reuses the SIP (Session Initiation Protocol) event package for conference state. Additionally, the notification mechanism includes support for the XCON data model and for partial notifications... In order to obtain notifications from a conference server's notification service, a client subscribes to the 'conference' event package at the server as specified in RFC 4575. Per the RFC, NOTIFY requests within this event package can carry an XML document in the "application/conference-info+xml" format. Additionally, per this specification, NOTIFY requests can also carry XML documents in the "application/xcon-conference-info+xml" and the "application/xcon-conference-info-diff+xml" formats. A document in the "application/xcon-conference-info+xml" format provides the user agent with the whole state of a conference instance. A document in the "application/ xcon-conference-info-diff+xml" format provides the user agent with the changes the state of the conference instance has experimented since the last notification sent to the user agent... Full Notifications: Subscribers signal support for full notifications by including the "application/xcon-conference-info+xml" format in the Accept header field of the SUBSCRIBE requests they generate. If a client subscribing to the 'conference' event package generates an Accept header field that includes the MIME type "application/xcon-conference-info+xml", the server has the option of returning documents that follow the XML format specified in the data model and are carried in "application/xcon-conference-info+xml" message bodies...


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

Headlines

Sponsors