The Cover PagesThe OASIS Cover Pages: The Online Resource for Markup Language Technologies
Advanced Search
Site Map
CP RSS Channel
Contact Us
Sponsoring CP
About Our Sponsors

Cover Stories
Articles & Papers
Press Releases

XML Query

XML Applications
General Apps
Government Apps
Academic Apps

Technology and Society
Tech Topics
Related Standards
Last modified: July 13, 2010
XML Daily Newslink. Tuesday, 13 July 2010

A Cover Pages Publication
Provided by OASIS and Sponsor Members
Edited by Robin Cover

This issue of XML Daily Newslink is sponsored by:
ISIS Papyrus

W3C Last Call Review for Web Services SOAP Assertions (WS-SOAPAssertions)
Doug Davis, Ashok Malhotra, Katy Warr, Wu Chou (eds), W3C Technical Report

Members of the W3C Web Services Resource Access Working Group have published a Last Call Working Draft of the standards-track specification Web Services SOAP Assertions (WS-SOAPAssertions). The document defines two WS-Policy assertions that can be used to advertise the requirement to use a certain version of SOAP in message exchanges. The WSRA Working Group believes all issues brought forth through previous Working Draft iterations have been addressed. W3C invites feedback through August 27, 2010.

From the document Introduction: "Using the Web Service Policy Framework and Web Services Policy Attachment specifications, an endpoint can indicate support for a variety of features. Two endpoints can then determine if they share compatible features through the policy intersection algorithm defined by the WS-Policy framework. This allows for a programmatic way to locate interoperable endpoints...

However, one key aspect of the message exchanges is whether either endpoint requires the use of SOAP 1.1 or SOAP 1.2. While this information might be obtainable through examination of a WSDL document, or implied through some out of band knowledge, there is no way to make this determination during the application of the policy intersection algorithm. This specification defines two new policy assertions that allows for this critical piece of information to be available during normal policy processing...

The elements defined in this specification may be extended at the points indicated by their outlines and schema. Implementations may add child elements and/or attributes at the indicated extension points but must not contradict the semantics of the parent and/or owner, respectively. As to compliance: an implementation is not compliant with this specification if it fails to satisfy one or more of the MUST or REQUIRED level requirements defined herein. A SOAP Node must not use the XML namespace identifier for this specification (documented in Section in 3.4 'XML Namespaces') within SOAP Envelopes unless it is compliant with this specification..."

See also: the W3C Web Services Resource Access Working Group

OASIS Creates CMIS Browser Binding Subcommittee
Staff, OASIS Announcement

Members of the OASIS Content Management Interoperability Services (CMIS) Technical Committee have created a 'CMIS Browser Binding Subcommittee'. CMIS defines a domain model and Web Services and Restful AtomPub bindings that can be used by applications to work with one or more Content Management repositories/systems. The goal in the CMIS Browser Binding Subcommittee activity is to design a third binding to provide CMIS data in a way that it is easily and directly consumable in a web browser. This would: "simplify uploading documents from a browser application, e.g., using multipart form; simplify parsing, e.g., using JSON instead of XML; simplify construction of required object metadata, e.g., constructing links..."

This new CMIS Browser Binding design activity is part of a larger TC v1.1/v2.0 effort to enhance the CMIS specification. Other candidate topics deferred or identified for priority include: Hierarchical/complex properties; Mixin types; WebDAV binding; Batch; Multiple content streams; Internationalization; Records Management; Pessimistic locking; Workflow integration with relevant standards such as BPMN 2.0; Content Tagging; More explicit exceptions; Exposing renditions; Commenting (beyond checkin-comments); Type management; Further definition of Users and some services...

The current CMIS Version 1.0 OASIS Standard already incorporates two bindings: (1) Restful AtomPub Binding. "In this binding, the client interacts with the repository by acquiring the service document. The client will request the service document by the URI provided by the vendor. The client will then choose a CMIS collection, and then start accessing the repository by following the references in the returned documents. This binding consists of a service document specifying at least CMIS service collections, atom collections, feeds and entry documents. The (2) CMIS Web Services Binding. The services and operations defined in the Domain Model are presented in the Web Services binding. The WSDL for these services reference two XSD documents. One defines elements for the primary data types of documents, folders, relationships and policies as well as collections of these types of objects. The second XSD defines the message formats for each of the CMIS services; the messages often refer to the data types defined in the first XSD schema; the WSDL presents the abstract services defined in the Services section."

Prototype work on a CMIS Browser Binding has been done in the context of Apache Chemistry (OpenCMIS sandbox) using Javascript and JSON. An early (2009) draft of a CMIS Browser Bindings document was presented to the OASIS CMIS TC by David Nuescheler, motivated by the following considerations: "The SOAP and AtomPub bindings of CMIS do not lend themselves to a straight forward consumption by standard web browsers and require the creation and use of large java script 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..."

See also: the OASIS CMIS Browser Binding Subcommittee

Metastorm Brings Workflow Modeling to the Cloud
Joab Jackson, Network World

Enterprise software provider Metastorm has launched an online workflow modeling service, called Metastorm M3. The service, which is hosted on the Microsoft Azure platform, can be used to model a variety of different enterprise concerns, such as goals, systems, workflows, rules and projects. The service provides twenty-three (23) modeling objects from which models can be built.

The company has also redesigned its modeling interface for this new service, using Microsoft Silverlight. It includes built-in help guides for those new to enterprise modeling. The output from this service can be integrated with Metastorm's enterprise architecture, business process automation and business process management software.

In addition to Metastorm M3, the company has also released a new software package, called Metastorm Smart Business Workspace, that allows an organization to set up a browser-based workspace for its workers. A single page holds a dashboard, chat software, links to reports and various widgets. The software allows users to fuse data from different applications. The package also includes a component, called the Metastorm Widget Designer, that can create small applications, called widgets, that draw data from Metastorm applications..."

From the announcement: "Metastorm, a leading provider of Business Process Management (BPM), Business Process Analysis (BPA), and Enterprise Architecture (EA) software for aligning strategy with execution, today announced the release of Metastorm M3—a cloud-enabled collaborative modeling suite. Metastorm M3 combines the most popular modeling types from Metastorm's enterprise software portfolio and delivers them in an intuitive, easy to use environment in the Cloud. Metastorm M3 enables an unlimited number of business and IT users to create and provide input into graphical models and to collaborate in real-time to deliver more accurate and effective representations of the organization and desired improvements..."

See also: the Metastorm announcement

The Curious History of Uniform Resource Names
Leslie Daigle, IETF Journal

"Sometimes it's hard to judge whether an engineering effort has been successful or not. It can take years for an idea to catch on, to go from being the butt of jokes to becoming an international imperative (IPv6). Uniform Resource Names (URNs), which are part of the Uniform Resource Identifier (URI) family, are conceptually at least as old as IPv6. While not figuring in international directives for deployment, they — and the technology engineered to resolve them — are still going concerns.

The curious thing is that since the URN working group (WG) concluded in 2002, these two aspects (the URN itself and its resolution system) have had almost completely independent histories. Does the world have a universally supported, persistent resource-naming infrastructure for Internet applications, as envisaged at the outset of the URN WG in 1996? No, not by any stretch of the imagination. Were the six-plus years of IETF engineering effort therefore wasted? No, not that either. Rather, the URN work has contributed certain important building blocks that have been used and reused in efforts that have followed...

According to the IANA registry, there are 40 formal URN namespaces registered today. The namespaces range from identifiers for IETF protocol resources to the Digital Video Broadcasting Project, to 3GPP, to ISBN. Very diverse communities of interest have rallied around the URN concept of a persistent, unique global identifier and established a namespace for their purposes. None of these use the formally established resolution mechanism (DDDS). However, approximately 25 RFCs reference the DDDS/NAPTR RFC for uses from ENUM to SIP.

While not classically successful, the URN work produced output that clearly has had value for high-impact derivative works. The work started with a vision for persistent identifiers, with a dedicated group of IETF workers interested in the problem space, and with a perceived market need for those identifiers. That single driving market never actually appeared. Reviewing the 40 registered formal URN namespaces, one would find it hard to detect a single unifying theme between them that could have led to a single resolution system that would have supported all of them..."

See also: the IETF 'urn' list archive

U.S. Feds Propose Rules to Strengthen Patient Privacy Rights
Lucas Mearian, ComputerWorld

"The U.S. Department of Health and Human Services (HHS) has proposed a new federal healthcare information privacy rule that would let patients restrict access to certain health information and ban the sale of patient data without consent.

David Blumenthal, head of the Office of the National Coordinator (ONC) for Health Information Technology, said the ONC is also working with White House Cyber Security Chief Howard Schmidt on a government-wide private security initiative that will prioritize health care for security improvement with respect to cyber-information.

In addition to boosting patient rights, the proposal would extend certain privacy and security rule requirements to business associates of organizations already covered by HIPAA rules, and establish new limitations on the use of protected health information for marketing and fundraising purposes...

The proposed rules would also expand a person's rights to access their information, restrict certain disclosures of protected health information to health plans, and establish new limitations on the use and disclosure of protected health information..."

New Release of Apache CouchDB
Staff, The CouchDB Project Announcement

Members of the Apache CouchDB development team announced the release of a Apache CouchDB Version 1.0.0: "This is a huge milestone for the CouchDB community, and we'd like to thank every single person who's helped us get this far. This project would be nothing without its community, and we are fortunate enough to be blessed with a very healthy one.

Apache CouchDB is a document-oriented database that can be queried and indexed in a MapReduce fashion using JavaScript. CouchDB also offers incremental replication with bi-directional conflict detection and resolution.

CouchDB provides a RESTful JSON API than can be accessed from any environment that allows HTTP requests. There are myriad third-party client libraries that make this even easier from your programming language of choice. CouchDB's built in Web administration console speaks directly to the database using HTTP requests issued from your browser. CouchDB is written in Erlang, a robust functional programming language ideal for building concurrent distributed systems. Erlang allows for a flexible design that is easily scalable and readily extensible.

Changes in this release: (1) more efficient header commits; (2) use O_APPEND to save lseeks; (3) faster implementation of pread_iolist(), which further improves performance on concurrent reads; (4) added authentication caching; (5) faster default view collation; (6) added option to include update_seq in view responses..."

See also: the Apache CouchDB Wiki

Revised IETF Internet Draft for vCard XML Representation Specification
Simon Perreault (ed), IETF Internet Draft

An updated level -04 Internet Draft has been published in IETF for the Standards Track vCard XML Representation specification. The document defines a XML schema of the vCard data format, used for representing and exchanging a variety of information about individuals and other structured entities (e.g., formatted and structured name and delivery addresses, email address, multiple telephone numbers, photograph, logo, audio clips, etc.). The vCard XML schema is expressed in the RELAX NG language and is presented in document Appendix A. The original vCard format is extensible so that new properties, parameters, data types and values (collectively known as vCard objects) can be registered with IANA. It is expected that these vCard extensions will also specify extensions to the XML format described in this document.

Principal changes in this revision include: (1) synchronization with the vCard Format Specification as published in the IETF Internet Draft 'draft-ietf-vcarddav-vcardrev-12'; (2) addition of the media type' application/vcard+xml' for IANA registration; (3) addition of rules for backslash escaping and quoting when converting; (4) addition of a description of for the 'vcards' markup element; (5) description of the group construct in XML.

"The vCard specification defines a data format for representing and exchanging information about individuals and other entities. It is a text-based format, as opposed to a binary format. This document defines an XML representation for vCard. The underlying data structure is exactly the same, enabling a 1-to-1 mapping between the original vCard format and the XML representation. The XML formatting may be preferred in some contexts where an XML engine is readily available and may be reused instead of writing a stand-alone vCard parser...

The general idea is to map vCard parameters, properties, and value types to XML elements. For example, the 'FN' property is mapped to the 'fn' element. That element in turn contains a text element whose content corresponds to the vCard property's value. vCard parameters are also mapped to XML elements. They are contained in the 'parameters' markup element, which is contained in property elements. A top-level 'vcards' element is used as root. It contains one or more 'vcard' element, each representing a complete vCard. The 'vcards' element MUST be present even when only a single vCard is present in an XML document. The group construct, as described in Section 3.2 of the draft vCard I-D, is represented with the XML 'group' element..."

See also: the vCard Format Specification

ID Thefts Go Unreported Despite Notification Laws
Mathew J. Schwartz, InformationWeek

"The Identity Theft Resource Center (ITRC) says one-third of breaches appear to be malicious, but a lack of transparency and accountability may be masking true extent of problem. ITRC reported that it had recorded 341 individual data breaches for the first six months of 2010. But hundreds more went unreported, said the organization. In addition, for 46% of breaches, the number of records potentially affected weren't disclosed, and for 38%, no cause was disclosed.

Why? Some states now harbor a protected breach list that is not made public at all, or is only accessible by exercising the Freedom of Information Act. One state, for example, had a list of 200 breaches, but for most, little information was disseminated, at least publicly, such as the number of records affected.

In addition, for medical data breaches, the Department of Health and Human Services (HHS) has created a 'risk of harm' threshold for notifications. Under HHS guidelines, if an organization determines that a data breach hasn't caused 'a significant risk of financial, reputational, or other harm to individual,' then it doesn't have to report the breach, either to the person whose information was breached or to law enforcement agencies...

Allowing organizations to conduct their own risk assessment, and then determine whether or not to notify people whose records have been affected, may be contributing to an underreporting of the actual extent of data breaches today, and providing an incomplete picture of which organizations adequately safeguard people's personal information...'

See also: the Identity Theft Resource Center

Simple-VPN: Simple IPsec Configuration
Shreyas Srivatsan, Maritza Johnson, Steven M. Bellovin, CSCU Technical Report

This Columbia University CS Technical Report (CUCS-020-10) presents Simple-VPN as an IPsec configuration compiler that tackles the complexities of IPsec configuration for VPNs. Abstract: "The IPsec protocol promised easy, ubiquitous encryption. That has never happened. For the most part, IPsec usage is confined to VPNs for road warriors, largely due to needless configuration complexity and incompatible implementations. We have designed a simple VPN configuration language that hides the unwanted complexities. Virtually no options are necessary or possible. The administrator specifies the absolute minimum of information: the authorized hosts, their operating systems, and a little about the network topology; everything else, including certificate generation, is automatic. Our implementation includes a multitarget compiler, which generates implementation-specific configuration files for three different platforms; others are easy to add.

The IPsec protocol, though having the advantage of operating transparently to applications running in the host system, has never taken off; one of the main reasons being the complexity of the protocol. This complexity has also led to interoperability problems between the various implementations of the protocol. Public key authentication used by IKE brings with it its own set of complexities. We solve the problem by creating a compiler that hides all these complexities from the end user. Based on security and performance considerations and the requirements of most people today, we make educated choices for most of the options provided, allowing the user to make very few choices... We have opted for safe alternatives. Thus, we prefer AES over DES. We ignore AH and always use ESP with authentication enabled.

We also argue that public key authentication becomes complex when the certificates used are multi-purpose. But in the situation where they are used solely for the purpose of authorization, and provide no other privileges, the stakes are not as high. Simple-VPN generates authorization only certificates which are tied to the machine that is part of the VPN, rather than to the identity of the user. This also allows for easy deployment of the VPN. Simple-VPN has been implemented as an extensible language, which can allow easy support for newer features and IPsec implementations.

The authors present the complete EZ-VPN Grammar and explain the various options provided. They feel that the current grammar is suffcient for most users, but have designed it in a way that it is easy to allow support for newer features in the future...."

See also: the IETF IP Security Maintenance and Extensions (IPSECME) WG

Future of Interoperability Standards Meeting 2010
Staff, CETIS Announcement

CETIS (Centre for Educational Technology and Interoperability Standards) is sponsoring a The Future of Interoperability Standards Meeting 2010 on September 24, 2010 at The Fish Room, Royal Society of Chemistry, Burlington House, London. This event, the second in a workshop/discussion series on the 'future of interoperability standards' "is of interest to those directly involved with the development of formal or informal interoperability specifications and standards, especially in education but also in the research and cultural heritage domains.

Whereas previously the emphasis was on policy and process and the relationship between formal and informal standards-development models, this time we will focus on the technical approaches to creating standards: how should we model and document standards. This could include questions of structure/segmentation, arguments about application of semantic web approaches, application models in relation to core models, how to handle statements about conformance. As before, position papers are invited...

Example position papers from the earlier January meeting (titles): "Collaboration Between Open, Informal Specification Communities and the Formal Standards World: The Role of the Open Web Foundation Agreements"; "Standards Experience: IMS Basic Learning Tools Interoperability"; "Issues With Open Source and Standards"; "Development of standards"; "The Best of Both Worlds: Formal Public Standardisation and Open Community Development"; "Developing Semantic-Web-friendly specifications"; "An Opportunities and Risks Framework For Standards"; "Supporting the Take-up of Specifications with Application Profiles and Conformance Testing"; "Categories and Purposes of (e-Learning) Standards"; "An Agile Approach to the Development of Dublin Core Application Profiles"; "Standards and SCORM: Maturity, Adoption, Process"; "SALTIS and LETSI Position Paper"; "Making Sense of the State of e-Learning Standards Developments"; "Future of Standards"; "Educational Metadata Standards"; "What is the Role of Standards to Facilitate Authoring of Educational Material"; "The Future of Interoperability Standards"; "Standards, Profiles, Interoperability"; "On the Role of Technical Standards for Learning Technologies."

A future CETIS event will consider the vital precursor to technical approaches: methods to surface and agree on the conceptual models. JISC CETIS, the Centre for Educational Technology and Interoperability Standards, provides advice to the UK Higher and Post-16 Education sectors on educational technology and standards..."

See also: the January 2010 Position Papers

Open-Source Hardware Standards Formally Issued
Daniel Terdiman, CNET

"There are thirteen (13) million-dollar open-source hardware companies, but there have been no standards governing what defines the still nascent field. Until now, that is. Unlike open-source software, because there have been no formal definitions, many people may not even be aware of the growing industry. But already some of those practicing its general principles have become household names among the geek set...

A group of signatories including Wired magazine editor and DIY Drones' Chris Anderson, Phil Torrone of Make magazine, David Mellis of MIT Media Lab and Arduino, Limor Fried of Adafruit, and Ayah Bdeir of New York's Eyebeam have publicly issued a formal definition of open-source hardware.

The basic elements of the standards are as follows: documentation; necessary software; derived works; free redistribution; attribution; no discrimination against persons or groups; no discrimination against fields of endeavor; distribution of license; license must not be specific to a product; license must not restrict other hardware or software; and license must be technology-neutral. That is a definition that might be considered familiar to many who have read much about free-software licensing..."

From the web site: "OSHW Draft Definition Version 0.3 is based on the Open Source Definition for Open Source Software and draft OSHW definition 0.2, further incorporating ideas from the TAPR Open Hardware License... Excerpts: (1) Documentation: The hardware must be released with documentation including design files, and must allow modification and distribution of the design files... (2) Necessary Software: If the hardware requires software, embedded or otherwise, to operate properly and fulfill its essential functions, then the documentation requirement must also include at least [...] (3) Derived Works: The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original hardware; (4) Free redistribution: The license shall not restrict any party from selling or giving away the project documentation as a component of an aggregate distribution containing designs from several different sources..." [Ed. note: Few agree on what "open" means or should mean in reference to "standards" and (arguably) "source".]

See also: the Open Source Hardware (OSHW) Draft Definition Version 0.3


XML Daily Newslink and Cover Pages sponsored by:

IBM Corporation
ISIS Papyrus
Microsoft Corporation
Oracle Corporation

XML Daily Newslink:
Newsletter Archive:
Newsletter subscribe:
Newsletter unsubscribe:
Newsletter help:
Cover Pages:

Hosted By
OASIS - Organization for the Advancement of Structured Information Standards

Sponsored By

IBM Corporation
ISIS Papyrus
Microsoft Corporation
Oracle Corporation


XML Daily Newslink
Receive daily news updates from Managing Editor, Robin Cover.

 Newsletter Subscription
 Newsletter Archives
Globe Image

Document URI:  —  Legal stuff
Robin Cover, Editor: