Cover Pages: XML Daily Newslink: Wednesday, 18 August 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:
Microsoft Corporation http://www.microsoft.com

Headlines

W3C Working Draft: Contacts API for Address Books
Public Review for OASIS OpenDocument Version 1.0 Errata
OASIS WS-Calendar Technical Committee Advances Draft Specifications
IETF Hypertext Transfer Protocol Bis WG Publishes HTTP/1.1 Drafts
W3C Web Services Resource Access WG Publishes Last Call Working Drafts
First International Workshop on Semantic Repositories for the Web
Tuscany SCA in Action
Java Web Services: WS-SecureConversation Performance
Musical Notation in XML: The Music Encoding Initiative (MEI)

W3C Working Draft: Contacts API for Address Books
Richard Tibbett (ed), W3C Technical Report

The W3C Device APIs and Policy Working Group has published a Working Draft for the Contacts API specification. This specification defines the concept of a user's unified address book — where address book data may be sourced from a plurality of sources—both online and locally. This specification then defines the interfaces on which third party applications can access a user's unified address book, with explicit user permission and filtering. The API itself is agnostic of any underlying address book sources and storage.

The Contacts API specification is built on top of an accompanying Contacts Writer API specification that enables read access to a user's unified address book. It defines the high-level interfaces required to add and remove contact information to and from a user's unified address book.

From the 'Contacts API' Introduction: "Every operating system and a large number of web-based service providers have different ways of representing address book information. Most users are required to maintain a plurality of contact lists which leads to multiple copies of address book data. The multiplicity of address books that a user is required to maintain often leads to disjointed and inconsistent information being stored across a user's address book providers.

Providing address book information to these service providers means handing over all of your data and trusting these providers with the security and privacy of storing and sharing of your information. When sharing this data with third parties users are, more often than not, required to hand over access to their whole address book. Users are implicitly required to trust third parties with all of their data when, in reality, the user may only wish, or need, to share a subset of their address book information so that an application can fulfill its purpose... This specification therefore focuses on controlled data sharing—making the user aware of the data that they will share and putting them at the centre of the data sharing process; free to select both the extent to which they share their address book information and the ability to restrict which pieces of information related to which contact gets shared..."

Public Review for OASIS OpenDocument Version 1.0 Errata
Patrick Durusau, Dennis E. Hamilton, Svante Schubert (eds), OASIS PRD

Members of the OASIS Open Document Format for Office Applications (OpenDocument) Technical Committee have approved Committee Draft 05 of Open Document Format for Office Applications (OpenDocument) Version 1.0 Errata for public review through September 01, 2010. The Open Document Format for Office Applications (OpenDocument) format, is an open, XML-based file format for office applications, based on OpenOffice.org XML.

This document is the second errata document for OpenDocument v1.0. It includes as first part the OpenDocument Format 1.0 Approved Errata 01, covering the first part the comments of the Japanese National Body (N0942) and in the new second part the second comments of the Japanese National Body (N1078) and the first of the British National Body (N1309).

Specifically: 'Errata Part 01' is identical with the OpenDocument Format 1.0 Approved Errata 01. It covers the first Japanese Defect Report (N0942) and includes references to ODF 1.0, ISO/IEC 26300 and N0942, the Japanese National Body comments provided for the reader's convenience.

'Errata Part 02' is new to the second errata document for OpenDocument v1.0. This part covers the second Japanese Defect Report (N1078) and the first British Defect Report (N1309 ) and includes references to the comments of the Japanese National Body (N1078) and British National Body (N1309) for the reader's convenience.

See also: the OASIS announcement

OASIS WS-Calendar Technical Committee Advances Draft Specifications
Toby Considine (ed), OASIS Working Drafts

Members of the OASIS Web Services Calendar (WS-Calendar) Technical Committee have progressed the draft WS-Calender Version 1.0 specification to Working Draft 09, and have determined to incorporate content from a draft CalWSRest specification into WS-Calendar.

The WS-Calendar TC was chartered to deliver a specification for creating, retrieving, updating, and deleting calendar events on a schedule. This specification is based on the forthcoming calendar web service specifications developed by CalConnect. Interested parties are invited to join the WS-Calendar TC at any time.

WS-Calender Version 1.0 (Working Draft 09), edited by Toby Considine, "describes a limited set of message components and interactions providing a common basis for specifying schedules and intervals to coordinate activities between services. The specification includes service definitions consistent with the OASIS SOA Reference Model and XML vocabularies for the interoperable and standard exchange of: (1) Schedules, including sequences of schedules; (2) Intervals, including sequences of intervals. These message components describe schedules and intervals future, present, or past (historical). The definition of the services performed to meet a schedule or interval depends on the market context in which that service exists..." WD -09 adds the CalWS outline into the draft.

The document "CalWSRest: Restful Web Service Protocol for Calendaring Version 0.1" (Draft 01), edited by Michael A. Douglass, "describes a RESTful web service for calendar access and update. According to the document Introduction: 'The CalWS protocol is built upon and makes the same assumptions about structure as the CalDAV protocol defined in IETF RFC 4791 and related specifications. It does not require nor assume the WebDAV nor CalDAV protocol but does make use of some of the same elements and structures in the CalDAV XML namespace.. Calendar resources, for example events and tasks are stored as named resources (files) inside special collections (folders) known as 'Calendar Collections'. This specification can be looked upon as a layer built on top of CalDAV and defines the basic operations which allow creation, retrieval, update and deletion. In addition, query operations are defined to allow efficient, partial retrieval of calendar data. This does not mean that a CalWS service must be built on CalDAV, merely that a degree of conformity is established such that services built in that manner do not have a significant mismatch. It is assumed that some CalWS services will be built without any CalDAV support..."

IETF Hypertext Transfer Protocol Bis WG Publishes HTTP/1.1 Drafts
Julian Reschke, Posting to W3C ietf-http-wg List

Members of the IETF Hypertext Transfer Protocol Bis (HTTPBIS) Working Group have published a collection of IETF Working Drafts for the seven-part HTTP/1.1 specification (HTTPbis) now under revision. "HTTP is one of the most successful and widely-used protocols on the Internet today. After years of implementation and extension, several ambiguities in the specification have become evident, impairing interoperability and the ability to easily implement and use HTTP.

The HTTPbis WG was chartered to: "incorporate errata and updates—e.g., references, IANA registries, ABNF; fix editorial problems which have led to misunderstandings of the specification; clarify conformance requirements; remove known ambiguities where they affect interoperability; clarify existing methods of extensibility; remove or deprecate those features that are not widely implemented and also unduly affect interoperability; where necessary, add implementation advice; document the security properties of HTTP and its associated echanisms (e.g., Basic and Digest authentication, cookies, TLS) for common applications..."

HTTP/1.1, Part 1: 'URIs, Connections, and Message Parsing' "defines the 'http' and 'https' Uniform Resource Identifier (URI) schemes, defines the generic message syntax and parsing requirements for HTTP message frames, and describes general security concerns for implementations." HTTP/1.1, Part 2: 'Message Semantics' "defines the semantics of HTTP messages as expressed by request methods, request-header fields, response status codes, and response-header fields." HTTP/1.1, Part 3: 'Message Payload and Content Negotiation' "defines HTTP message content, metadata, and content negotiation." HTTP/1.1, Part 4: 'Conditional Requests' "defines request header fields for indicating conditional requests and the rules for constructing responses to those requests." HTTP/1.1, Part 5: 'Range Requests and Partial Responses' "defines range-specific requests and the rules for constructing and combining responses to those requests." HTTP/1.1, Part 6: 'Caching' "defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages." HTTP/1.1, Part 7: 'Authentication' "defines HTTP/1.1 access control and authentication."

See also: the HTTPbis WG Status Pages

W3C Web Services Resource Access WG Publishes Last Call Working Drafts
Doug Davis, Ashok Malhotra, Katy Warr, Wu Chou (et al, eds), W3C WDs

Members of the W3C Web Services Resource Access Working Group have issued a second Last Call for review of Web Services specifications: Enumeration (WS-Enumeration), Event Descriptions (WS-EventDescriptions), Eventing (WS-Eventing), Fragment (WS-Fragment), Metadata Exchange (WS-MetadataExchange), SOAP Assertions (WS-SOAPAssertions), and Transfer (WS-Transfer). Public comments is invited through September 17, 2010. These specifications are expected to be published and maintained as final W3C Recommendations after review and refinement.

This Working Group was chartered to standardize a general mechanism for accessing and updating the XML representation of a resource-oriented Web Service and metadata of a Web Service, as well as a mechanism to subscribe to events from a Web Service.

"WS-Enumeration" describes a general SOAP-based protocol for enumerating a sequence of XML elements from a SOAP enabled information source. "WS-EventDescriptions" describes a mechanism by which an endpoint can advertise the structure and contents of the events it might generate. "WS-Eventing" describes a protocol that allows Web services to subscribe to or accept subscriptions for notification messages. "WS-Fragment" extends the WS-Transfer specification to enable clients to retrieve and manipulate parts or fragments of a WS-Transfer enabled resource without needing to include the entire XML representation in a message exchange.

"WS-MetadataExchange" defines how metadata associated with a Web service endpoint can be represented as WS-Transfer resources or HTTP resources, how metadata can be embedded in WS-Addressing endpoint references, how metadata could be retrieved from a metadata resource, and how metadata associated with implicit features can be advertised. "WS-SOAPAssertions" defines two WS-Policy assertions that can be used to advertise the requirement to use a certain version of SOAP in message exchanges. "WS-Transfer" defines a mechanism for acquiring XML-based representations of entities using the Web service infrastructure using two types of entities: (1) Resources, which are entities addressable by an endpoint reference that provide an XML representation, and (2) Resource factories, which are Web services that can create new resources...

First International Workshop on Semantic Repositories for the Web
Organizing Committee, SERES 2010 Announcement

A Call for Participation has been issued in connection with the First International Workshop on Semantic Repositories for the Web (SERES 2010), to be held at the Ninth International Semantic Web Conference on November 8, 2010, in Shanghai, China. Natasha Noy, Peter Yim, and Jeff Pan will be keynote speakers. Paper submissions are due by August 27, 2010.

The Workshop brings together "researchers and practitioners active in the design, development and application of semantic web technology, semantic registries and repositories, repository editors, modularization techniques, versioning systems and issues around federated ontology systems. As some repository-related tools are already under development, and repositories are a crucial part of business infrastructure, the program also address progressive Chief Technology Officers interested in using these technologies...

Ontologies and Linked Data vocabularies are being actively developed and used by numerous applications. Several domains are making their vocabularies available for others to reuse. In addition, good practices when developing ontologies are often followed, particularly for producing reusable modules. The Semantic Web is a modular and highly federated environment of reusable knowledge sources; these provide the meaning so that SW applications change our experience of the web. Within this context, the need for repositories delivering the added value that makes the SW a concrete step beyond our current experience of the web is palpable. SERES addresses issues around semantic repositories within the context of the SW...

The number of ontologies being built and made available for reuse has increased steadily in the last few years. Semantic Web search engines such as Swoogle and Watson currently index several tens of thousands of them; there are also systems specifically designed to support the publication of ontologies, e.g. Cupboard, NCBO Bioportal, and ONKI. Some tools also support editing features, e.g. Neologism, Knoodl. While being a foundation for the Semantic Web, this new environment where ontologies are shared and interlinked online also poses new challenges; fostering thus a number of research projects aiming to understand, amongst others, ontology reuse, storage, publication, versioning, quality control, evaluation, retrieval and modularization..."

See also: the ISWC 2010 web site

Tuscany SCA in Action
Boris Lublinsky, InfoQueue

"A new book by Simon Laws, Mark Combellack, Raymond Feng, Haleh Mahbod and Simon Nash Tuscany SCA in Action provides a simple step-by-step guide on how to develop applications leveraging SCA and Apache Tuscany.

This practical book is comprehensive, hands-on guide to Service Component Architecture, Apache Tuscany's specific SCA implementation (based on Java SCA v1.x) and the ways to use Tuscany to build applications. The books starts by explaining main concepts of SCA including components, services, references and composite applications and the way they are used for implementing SOA-based solutions. It then introduces a travel booking example, used throughout the book to explain details of SCA/Tuscany-based implementations. The book covers a wide variety of topics from implementing and binding SCA components, including data representation and transformation and invocation policies to deploying Tuscany-based applications to Tuscany runtime architecture, including ways to extending and embedding Tuscany's runtime..."

From the interview: "Q: hat is the real difference between component-based development and SOA—is it just a set of technologies used? A: In the context of software development people often look to components to provide a separation of concerns. Component builders define an interface and create business logic behind that interface. Services are often described as more coarse grained applications that provide functions to other applications with an emphasis on remote hosting. SOA promotes the construction of applications by wiring multiple services together. SOA, as a set of design principles, doesn't prescribe how you actually implement services or indeed how you could formally describe the relationships between services that are wired together.

Service Component Architecture (SCA) is a standards based way of doing both of these things. A programming model for SOA if you like. From its name you may have guessed that SCA combines the concepts of both components and services. In SCA, a component's business logic is provided by its implementation. A SCA component also provides one or more services which define how other components can access this business logic. This separation of concerns allows components to be wired and re-wired together without affecting a component's implementation. SCA provides an assembly model that allows you to describe how components are wired together, via the services they provide, into what it calls composite applications. SCA places no restrictions on the size or scope of a composite application..."

See also: Apache Tuscany

Java Web Services: WS-SecureConversation Performance
Dennis Sosnoski, IBM developerWorks

In this article the author explains how to configure WS-SecureConversation in the three main open source Java Web services stacks — Apache Axis2, Metro, and Apache CXF — and demonstrates the impact on performance compared to WS-Security asymmetric encryption.

WS-SecureConversation lets you secure ongoing Web service message exchanges with less processing overhead than plain WS-Security. The client in a WS-SecureConversation message exchange first connects to a Security Token Service (STS) endpoint to establish a security context that includes a shared secret key. This shared secret key is then used as the basis for encrypting and/or signing messages exchanged with the target service. The security context is identified by a Security Context Token (SCT), returned by the STS to the client. The SCT is included by the client in all requests to the service as part of the secure conversation, and referenced by the service in all responses.

As with plain WS-Security, the security configuration is defined in a WS-Policy document. When you use WS-SecureConversation: two separate security configurations are present in the policy for the service, one for the message exchange with the STS and the other for the target service. The STS security configuration is nested inside the policy definition of the secure conversation token...

To be of any benefit, WS-SecureConversation requires an ongoing sequence of messages over a relatively short span of time. If you use it for a service that clients access on a one-off basis, you'll actually be adding a lot of overhead that's due to message exchanges between the client and the STS..."

Musical Notation in XML: The Music Encoding Initiative (MEI)
Perry Roland (et al., eds), Community Specification

An updated XML schema has been published by developers in the Music Encoding Initiative (MEI) project. The Music Encoding Initiative (MEI) schema "is a set of rules for recording the intellectual and physical characteristics of music notation documents so that the information contained in them may be searched, retrieved, displayed, and exchanged in a predictable and platform-independent manner. The schema is provided in both RelaxNG (RNG) and W3C (XSD) schema forms. Both versions consist of a driver file (mei-all), modules (such as analysis, cmnOrnaments, etc.) and auxiliary files (defaultClassDecls and datatypes)...

Music Encoding Initiative strives to create a semantically rich model for music notation that: (1) accommodates the encoding of common Western music, but is not limited to common music notation; (2) is designed by the scholarly community for scholarly uses, but does not exclude other uses; (3) provides for the common functions of traditional facsimile, critical, and performance editions; (4) has a modular structure that permits use dependent on the goals of scholars; and (5) is based on open standards and is platform-independent; (6) employs XML technologies; (7) permits the development of comprehensive and permanent international archives of notated music as a basis for editions, analysis, performances, and other forms of research...

As a natural-language translation of the MEI schema, the tag library conveys information about the three principal tasks accomplished by the schema. First, the schema breaks down the content of music notation documents into data fields or categories of information called 'elements'. All of these elements are named, defined, and described in the MEI Tag Library. Second, the tag library identifies and defines attributes associated with those elements. Attributes are characteristics or properties that further refine the element. Last, and perhaps most importantly, the tag library expresses the schema structure by explaining the relationship between elements, specifying where the elements may be used and describing how they may be modified by attributes...

Contributors are involved in several MEI Projects. The MEI editor currently in development aims to enable the users to view and graphically edit MEI-encoded music documents in CWN (Common Western Notation). The supported function set is only a subset of the features contained in MEI, excluding more exotic features such as medieval neumes and features that are graphically complex to implement... One of the editors of the new edition of Haydn's complete works, reports on the possibilities that MEI offers for scholarly music editions, using partial encodings of two aria arrangements made by Joseph Haydn for the Esterhazy court..."


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

Headlines

Sponsors