Cover Pages: XML Daily Newslink: Thursday, 28 May 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:
Oracle Corporation http://www.oracle.com

Headlines

Content Management Interoperability Services: CMIS Browser Bindings
Java Content Repository (JCR) - CMIS Comparison
NCMIS: .NET Content Management Interoperability Services
Updated Candidate Recommendation for XProc: An XML Pipeline Language
World Wide Web Consortium Launches Office in Senegal
Updated White Paper: Key Management Interoperability Protocol (KMIP)
Five Mechanical Approaches to Make an XSD Profile
What Will Happen to Your Crypto-Keys When You Die?

Content Management Interoperability Services: CMIS Browser Bindings
David Nuescheler (ed), Contribution to the OASIS CMIS TC

An initial draft version of Content Management Interoperability Services: Browser Bindings has been posted to the OASIS CMIS TC list. This document describes the 'Browser Bindings' of CMIS. In early testing of the two existing Bindings (SOAP and AtomPub), despite being HTTP based, basic use cases can not be covered when using a standard web browser. The intention of this document is to cover that gap and make CMIS a 'Browser-enabled' protocol that delivers on the promise of 'Browser mash-up' as a use cases. Motivation: Currently the SOAP and AtomPub bindings of CMIS don't lend themselves to a straight forward consumption by standard web browsers and require the creation and use of large Javascript libraries for the most basic use cases. Other use cases as simple as 'uploading a file' even cannot be covered at all with a browser talking to a CMIS repository. The lack of this ability even triggered conversations in the TC about having server-sided proxies that would again speak a proprietary protocol just to able to translate CMIS to a protocol that allows for mash-ups and browser interaction, which seems like very undesirable effect when specifying an HTTP based protocol for consumption by browser. Since mash-ups and simple browser interaction is a stated goal and use case of CMIS this document tries to close this gap by introducing a lightweight and easy to consume binding that makes CMIS effective in a standard Web environment... The goal of this specification is to offer a simple protocol that is efficient from a network perspective and intuitive to use from a standard (Javascript enabled) web browser. This document does not attempt to cover the full breadth of CMIS and will always compromise edge-cases for simplicity. Also this binding does not necessarily attempt to cover all the features and domain model expressed in CMIS, but there are no implicit limitations on how much of the domain model is covered. The binding should be designed in a fashion that allows web browsers and other web infrastructure (such as spiders) to easily introspect the contents of the repository and interact with it. The overall goal of this document is to produce a binding that is intuitive to use and hence ease of use is the most important guiding principal..."

Editor's note: "First of all I would like to mention that the guiding principles and usecases are focused a very simple interaction with the browser using the domain model of CMIS delivering on the Mashup use case. Consider this draft a wishlist from a browser application developers perspective, rather than something that has been vetted against potential implementation efforts on the server side. In our implementations we so far found that the protocol is simple to implement on the server side in general and extremely efficient over the wire given its very small network footprint... Dave Caruana kindly volunteered to help out with feedback in the process and has already sent some very thoughtful discussion points, but not all of those have been incorporated in this draft. Sorry about that and thanks a lot to Dave..."

Java Content Repository (JCR) - CMIS Comparison
David Nuescheler, Day Software Blog

David Nuescheler, serving as liaison between the Java Content Repository (JCR - JSR-170/283) and CMIS activities, provided a slideset presentation and summary of the similarities and differences. Summary: "There seems to be a desire to discuss the relationship between CMIS and JCR similar to the desire to discuss JCR and WebDAV or, more recently, JCR and Atom...

(1) API vs. Protocol: JCR specifies an API (Application Programming Interface) while CMIS specifies two protocol bindings. Much like the Servlet API in Java and the HTTP protocol are complementary this is also the case for JCR and CMIS. Similar arguments have been made for Atom and WebDAV. JCR and CMIS are complementary in this aspect. (2) Focused Model vs. Generally Applicable Model: JCR specifies a very general model based Node and Properties that lends itself to the implementation of specific domain models. On the hand, CMIS specifies such a specific domain model for document management. The CMIS domain model can easily be implemented in a JCR model. Some people could say that if one were to implement CMIS from scratch a JCR repository would be the ideal starting point as it provides the perfect infrastructure to do that. I think it is one of the most important assets of CMIS that it exposes the domain model of document management. It will be helpful in further standard discussions to have an established consensus on the domain model amongst the document management vendors. (3) Every JCR repository is a CMIS repository: Based on this type of compatibility between CMIS and JCR Apache Chemistry (currently in incubation) implements CMIS on top of JCR, amongst other things. This turns every JCR compliant repository into a CMIS compliant repository without any development effort. Even better news are that Chemistry gets bootstrapped with numerous existing JCR repositories and connectors. These repositories can thus expose CMIS right from the start. (4) Interop vs. Infrastructure: There is always a tension in a specification to address both 'interop' and 'infrastructure' needs. Interop enables different repositories to be compatible on some level, whereas infrastructure provides users with a platform to build upon. There were tendencies in the JCR expert group to support users of the API in a way that they could build real-life applications. Hence, the infrastructure aspect was always a very important aspect. Because of that, the least common denominator aspects that come with 'interop' were only a part of the equation. For CMIS, offering general purpose infrastructure is a stated non-goal. CMIS is only concerned with 'interop'. Consequently, JCR is very successful with the number of users and applications built on top of JCR, while I believe that it is the goal of CMIS to be very successful with number of implementations...

In terms of perception I think CMIS reduces the expectation on JCR to be a least common denominator interop spec. I welcome that because both specification efforts will be able to evolve in a more agile fashion when they focus on 'interop' and 'infrastructure' needs respectively. In summary, I am very excited to have a specification both on the protocol and on the API level addressing the needs of a more open standards based content management landscape...

See also: the slide presentation

NCMIS: .NET Content Management Interoperability Services
Allan Thraen (et al, eds), Open Source CodePlex Project

The OASIS draft Content Management Interoperability Services (CMIS) specification is now being implemented widely in a variety of contexts. In May 2009, Allan Thraen and others initiated sn open source 'NCMIS: .NET' project on CodePlex. NCMIS is a "Dotnet library that will implement the core of the Content Management Interoperability Services standards proposal (CMIS) along with a toolbox for building your own implementations of CMIS. The goal of this project is to provide a library and toolbox that allows develops to produce and consume CMIS, as defined in the OASIS [CMIS Technical Committee] Proposal. It is still being developed, but here is an outline of the suggested contents of this library toolbox: (1) Business classes and related enums for all CMIS entities: Repository, Document, Folder, Policy, Relationship, Property; (2) Protocol handlers for REST/ATOM and SOAP as defined in the proposal; (3) Abstract base classes for producers that can be inherited and extended to implement your own CMIS producer; (4) Sample producer that you can use to test consumers against; (5) .NET based CMIS Explorer to explore and test your CMIS producers; (6) CMIS validator; (7) ASP.NET Virtual Path Provider sample consumer; (8) System.IO sample producer..."

See also: CMS Wire

Updated Candidate Recommendation for XProc: An XML Pipeline Language
Norm Walsh, Alex Milowski, Henry Thompson (eds), W3C Technical Report

Members of the W3C XML Processing Model Working Group have published an updated version of the "XProc: An XML Pipeline Language" Candidate Recommendation. Changes are presented in a color-coded diff-marked version, as summarized in a status section of the document. The W3C Working Group is publishing this revised Candidate Recommendation in order to publicize the decisions that it has made so far in addressing comments received since entering Candidate Recommendation. The Working Group believes that this draft addresses all of the comments that have been raised as of 01-May-2009. The Working Group will request to advance to Proposed Recommendation as soon as it can demonstrate sufficient implementation experience. It successfully gathered considerable such experience and believes that relatively little work remains. An ongoing implementation report will be maintained. "XProc: An XML Pipeline Language" is a language for describing operations to be performed on XML documents. An XML Pipeline "specifies a sequence of operations to be performed on a collection of XML input documents. Pipelines take zero or more XML documents as their input and produce zero or more XML documents as their output. A pipeline consists of steps. Like pipelines, steps take zero or more XML documents as their inputs and produce zero or more XML documents as their outputs. The inputs of a step come from the web, from the pipeline document, from the inputs to the pipeline itself, or from the outputs of other steps in the pipeline. The outputs from a step are consumed by other steps, are outputs of the pipeline as a whole, or are discarded. There are three kinds of steps: atomic steps, compound steps, and multi-container steps. Atomic steps carry out single operations and have no substructure as far as the pipeline is concerned. Compound steps and multi-container steps control the execution of other steps, which they include in the form of one or more subpipelines..."

World Wide Web Consortium Launches Office in Senegal
Staff, 3C Announcement

W3C has announced the launch of its first W3C Office in West Africa. The W3C Senegal Office will be hosted by the Ecole Supérieure Polytechnique (ESP), attached to the UCAD (Université Cheikh Anta Diop), in Dakar, Senegal. With this first French-speaking office, W3C looks forward to increasing interaction with the French-speaking community, especially neighboring countries in Africa. The opening ceremony will be held on 27-May-2009, as part of the eLearning Africa conference program. According to a recent OSIRIS report, only 6.1% of people in Senegal have Internet access. However, signs do indicate a trend towards increased IT availability, in part due to increased demand from institutes of higher education in the country. In Africa, and particularly in Senegal, a number of IT sectors are showing strong growth, including e-commerce solutions, telecommunications, e-banking, CRM, mobile Internet, network integration, and Web application development. Senegal's strength in the Internet and mobile sectors will also help the country narrow the digital divide. W3C has been involved in the past few years (through Workshops and Interest Groups) in how mobile technology can foster economic development in this sort of emerging market... The launch of the W3C Senegal Office is part of the Digital World Forum project (European Union's 7th Research Framework Programme - FP7) which seeks to understand how low-cost technologies can help bridge the digital divide...

Ecole Supérieure Polytechnique (ESP), host of the new W3C Senegal Office, is a renowned engineering school whose primary goals are to provide higher education in preparation for the functions of supervision in production and services; to conduct research activities aimed at continuous improvement, adaptation and participation in scientific and technological developments; and to carry out expert evaluations for public and private enterprise. The W3C Senegal Office will be managed jointly by Ibrahima Ngom, Project leader, from Department of Computer Science of ESP and Alex Corenthin, head of ISOC Senegal.

The World Wide Web Consortium (W3C) is an international consortium where Member organizations, a full-time staff, and the public work together to develop Web standards. W3C primarily pursues its mission through the creation of Web standards and guidelines designed to ensure long-term growth for the Web. As its Members work to realize the full potential of the Web, W3C collaborates with regional organizations wishing to further W3C's mission. The W3C Offices assist with promotion efforts in local languages, help broaden W3C's geographical base, and encourage international participation in W3C Activities. W3C has Offices in: Australia; the Benelux countries; Brazil; China; Finland; Germany and Austria; Greece; Hungary; India; Israel; Italy; Korea; Morocco; Senegal; Southern Africa; Spain; Sweden; and the United Kingdom and Ireland.

See also: the W3C news item

Updated White Paper: Key Management Interoperability Protocol (KMIP)
KMIP Specification Developers, OASIS White Paper

An updated White Paper has been released describing the motivations and goals of the new OASIS key management technical activity in the KMIP TC. Key Management Interoperability Protocol (KMIP): Addressing the Need for Standardization in Enterprise Key Management describes how KMIP represents a significant step forward in securing information infrastructure throughout the industry. KMIP's creation and subsequent adoption by industry vendors will reduce the complexity of encryption management for enterprises by building interoperability into the key management environment.

From the White Paper Executive Summary: The increasing use of encryption, certificate-based device authentication, asymmetric key pairs and digital signature reflects the critical importance of cryptography in addressing regulatory requirements, protecting intellectual property and controlling the exposure of sensitive information. However, the widespread use of these and other cryptographic technologies is complicated by inconsistencies and duplication in the key management systems supporting the applications, devices and systems using these technologies. For example, each native tape encryption system tends to have its own key management system, separate from the key management system for application encryption, or database encryption, or file encryption. Full-disk encryption systems for laptops have their own key management systems, as do encryption systems for disk-array storage environments and content management systems. Asymmetric key pairs and digital certificates similarly have their own key management systems as well. This proliferation of key management systems results in higher operational and infrastructure costs for enterprises using encryption, certificates, asymmetric key pairs and other cryptographic technologies.

Even in those cases where a single key management system can support multiple types of security objects and multiple kinds of cryptographically-enabled systems, there are typically different communication protocols between the key management servers and each of the cryptographic clients that communicate with it. An enterprise key management system, for example, is likely to have to communicate with an encrypting tape drive using a communication protocol specific to that tape drive, or with a SAN switch by means of a communication protocol specific to that switch, or with an application requiring asymmetric keys with yet another communication protocol and so on. This proliferation of protocols, even when supported by a single enterprise key manager, results in higher costs for developing and supporting the key manager; costs that ultimately get passed on to the enterprises deploying security solutions. The Key Management Interoperability Protocol (KMIP), recently introduced as a new technical committee OASIS, establishes a single, comprehensive protocol for communication between enterprise key management servers and cryptographic clients. By defining a protocol that can be used by any cryptographic client, ranging from a simple automated electric meter to very complex disk-arrays, KMIP enables enterprise key management servers to communicate via a single protocol to all cryptographic clients supporting that protocol. Through vendor support of KMIP, an enterprise will be able to consolidate key management in a single enterprise key management system, reducing operational and infrastructure costs while strengthening operational controls and governance of security policy...

Five Mechanical Approaches to Make an XSD Profile
Michael Champion, Posting to W3C List www-tag

In this posting the author contributes to a (fascinating) thread on the W3C TAG's public list 'www-tag' about significant next steps in the design of W3C XML Schema (XSD). Michael writes: "Taking off the spokesperson hat and speaking only for myself: I am very sympathetic to the critiques of XSD, and in another time would have enthusiastically endorsed Rick's Recommendations to fix its foundations rather than patch its cracks. My experience in the XML and web services teams at Microsoft has convinced me, however, that attempts to fix XSD (and XML for that matter) do more harm to the core value proposition of interoperability than they benefit functionality, usability, and so on. XML/XSD with all its warts is used in an astonishingly large number of ways and places, and I've learned about many them by having to deal with the fallout from "improvements" to the specs and implementations. Even the apparently minor changes in XML 1.0 5th edition have great potential to undermine XML-based interoperability, in ways that I never thought about until we tried to implement it and found that it created chaos in the higher levels of the XML stack. If XSD 1.1 scrupulously avoids breaking changes while fixing some of the flaws, it has some chance of getting traction, I don't know. As the TAG discovered, versioning is an extremely hard problem that we really don't know how to solve, so W3C needs to be excruciatingly careful about new versions of the specs for technologies that are unknowingly used by hundreds of millions of people every day. That's not to say we're stuck with the status quo, only that replacements for XML / XSD 1.0 are going to have to prove themselves in new environments first, and we should be assuming a conscious migration rather than a silent update from the current to the new standards..."

Rick Jelliffe has posted several programmatic essays, calling for new directions, and in one key posting, described approaches to profiling, or splitting the XML Schema specification into layers or sub-languages. For example: (1) Exchange model: One of the biggest early success stories in vendor-cooperative standards setting was the OASIS CALS Exchange Table Model: now it is part of history though it has influenced all subsequent table models since... There are now several profiles out: the W3C databinding minimum and maximum, the WS-I profile, the UN profile, etc. An algorithmic approach like the CALS approach could be used. (2) Modularity model: Chop the 250 page Structures plus the datatypes specs into different severable parts: Grammars and particles with [subpart] Additional constraints Key and uniqueness; Assertions; Built-in Datatypes; Schema location and assembly; Complex type derivation and assembly; Simple derivation... and encourage implementators to implement fully each part that they implement. (3) Set-based selection: Start with a private syntax for ISO/OASIS RELAX NG using XSD-namespace elements, then create an extra layer of syntax and semantic checking on RELAXSD ... The result [is that] all XSD Lite documents can be trivially converted to RELAX NG... (4) Resolved schemas: Many of the features of XSD are syntactic sugar. They may be useful for modelling, but they do not actually add any expressive power. And they come at a heavy cost. A resolved schema would be one in which a full XSD version 1.n schema had been re-written to remove syntactic sugar... In fact, this is how the RELAX NG specification is written.. (5) Schema versus Instance validation: the specification could be refactored into two parts, (a) Validation that the XSD schema is correct and (b) Validation that an instance is correct against the XSD schema...

What Will Happen to Your Crypto-Keys When You Die?
Cory Doctorow, BoingBoing Blog

"I'm working out my will, power of attorney, literary executor and related logistics... I'm not sick or anything, it's just crazy to have a family and be intestate... and one thing that came up today is what to do with my GPG keys and (especially) the 128-bit AES keys on my user partitions on my various machines. Right now, I carry the passphrases around in my head, which is fine, unless I drop dead, get hit by a bus, etc. What do you-all do with your cryptokeys? Keep 'em with a lawyer and hope that attorney-client privilege will protect them? Safe-deposit box? Friends? Under the mattress? Do you worry that if your friends have your keys, they can be subpoenaed or suborned?


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

Headlines

Sponsors