Cover Pages: XML Daily Newslink: Thursday, 26 March 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:
Primeton http://www.primeton.com

Headlines

Portable Contacts Implementation: Take Your Google Contacts With You
OWL 2 Web Ontology Language Document Overview: First Public Working Draft
OpenGIS Web Coverage Processing Service (WCPS) Interface Standard
Mapping ICOM and CMIS Abstract Models: OASIS Liaison Activity
Cross-Origin Resource Sharing Draft Published

Portable Contacts Implementation: Take Your Google Contacts With You
Lane LiaBraaten, OpenSocial Team Announcement

Lots of websites ask you to invite your friends when you sign up, and for good reason; the web is more fun when you can share your experiences with other people. However, too many of these sites access your list of friends by asking for your username and password so they can sign in as you and scrape your contact lists. The problem is that once a website has your password, it can access all sorts of data, not just your contacts. Portable Contacts to the rescue! Portable Contacts (affectionately known as "PoCo") is an open standard that aims to make it easier to access "who-you-know" information in a secure way—this means sites don't have to employ the "password anti-pattern" of scraping websites. Using PoCo is 'easy' to use because it builds on existing standards and libraries. In fact, PoCo uses the same data format as the OpenSocial REST protocol. The 'secure' part is provided by OAuth, an authentication mechanism that allows users to grant access to only certain sets of data (address books in this case). Web developers can now access Google Contacts using the OAuth and Portable Contacts standards. You can use Plaxo's Portable Contacts test client to send some test queries. Just enter your OAuth key, hit the "Grant Access" button to authorize access to your Google Contacts, and start submitting queries to see PoCo in action..." About the Portable Contacts community specification: "The goal of Portable Contacts is to make it easier for developers to give their users a secure way to access the address books and friends lists they have built up all over the web. The protocol is a combination of OAuth, XRDS-Simple, and a wire-format based on vCard harmonized with schema from OpenSocial. Specifically, it seeks to create a common access pattern and contact schema that any site can provide, well-specified authentication and access rules, standard libraries that can work with any site, and absolutely minimal complexity, with the lightest possible toolchain requirements for developers. By far the easiest way to start understanding the specification is to jump to the example in the Appendix. The format and meaning of the response should be readily apparent, and the majority of this document is merely an attempt to formalize the details of what should be relatively clear from this example..."

OWL 2 Web Ontology Language Document Overview: First Public Working Draft
Jie Bao, Diego Calvanese (et al.), W3C OWL Working Group Technical Report

W3C announced that members of the OWL Working Group have published a First Public Working Draft for the "OWL 2 Web Ontology Language Document Overview". A Wiki Version of this document identifies relevant text that may be updated. The OWL 2 Web Ontology Language, informally OWL 2, is an ontology language for the Semantic Web with formally defined meaning. Ontologies are formalized vocabularies of terms, often covering a specific domain and shared by a community of users. They specify the definitions of terms by describing their relationships with other terms in the ontology. OWL 2 is an extension and revision of the OWL Web Ontology Language developed by the W3C Web Ontology Working Group and published in 2004. OWL 2 is being developed (and this document was written) by a follow-on group, the W3C OWL Working Group. OWL and OWL 2 are designed to facilitate ontology development and sharing via the Web, with the ultimate goal of making Web content more accessible to machines... OWL 2 ontologies provide classes, properties, individuals, and data values and are stored as Semantic Web documents. OWL 2 ontologies can be used along with information written in RDF, and OWL 2 ontologies themselves are primarily exchanged as RDF documents. This document, part 1 of 13 in the OWL 2 document set, serves as an introduction to OWL 2 and the various other OWL 2 documents. It describes the various syntaxes for OWL 2, the different kinds of semantics, the defined profiles (sub-languages), and the differences between OWL 1 and OWL 2.

See also: the W3C news item

OpenGIS Web Coverage Processing Service (WCPS) Interface Standard
Staff, Open Geospatial Consortium Announcement

OGC has announced the adoption and availability of the OpenGIS Web Coverage Processing Service (WCPS) Interface Standard. WCPS defines a language for retrieval and processing of multi-dimensional geospatial coverages representing sensor, image, or statistics data. Services implementing this language provide access to original or derived sets of geospatial coverage information, in forms that are useful for client-side rendering, input into scientific models, and other client applications.

See also: the OGC standard

Mapping ICOM and CMIS Abstract Models: OASIS Liaison Activity
Eric S. Chan, Technical Presentation

In a posting to the OASIS CMIS TC, Eric S. Chan (OASIS ICOM TC Chair) writes: "I am initiating the liaison between CMIS and ICOM technical committees to leverage each other's technologies. I have attached the slides describing the ICOM TC Charter and potential mappings between ICOM and CMIS abstract models...." Excerpt from the prose portion of the presentation (see UML model diagrams for details): "ICOM TC Charter Scope is to (1) specify the normative standards for collaboration objects, along with their attributes, relationships, constraints, and behavior, and (2) to specify the non-normative guidelines (providing architectures or use-case scenarios) for a new workspace-oriented protocol for shared workspaces that support a full range of collaboration activities. [However] the detail bindings of ICOM abstract model to any specific programming languages and over-the-wire protocols will be handled through separate related TCs... Mappings between ICOM and CMIS: ICOM abstract model can define standard object types in CMIS. ICOM calendar, task list, forum, topic, address book, conference, and trash can define standard folder types in CMIS ICOM document, unified message, instant message, wiki page, contact, calendar occurrence, calendar invitation, task to do, task assignment, etc., can define standard document types in CMIS ICOM subscription, reminder, workflow, and access control can define standard policy types in CMIS ICOM n-nary bond can represent a group of 1-1 relationships in CMIS... The proposed ICOM entity is a tuple with a globally unique ID and an optional name. Virtually all ICOM objects are entities, some of which can map to CMIS Folder, Document, Policy, and Relationship objects. Access to every entity is controlled through an access control policy. Each entity can have zero or more markers, subscriptions, reminders, and bonds associated with it... ICOM Marker: ICOM Marker (includes Tag/Label and Category) needs a counterpart in CMIS—new object type in CMIS?

Cross-Origin Resource Sharing Draft Published
Anne van Kesteren, W3C Technical Report

W3C published an update to the "Cross-Origin Resource Sharing" specification. The document was produced by members of the Web Applications (WebApps) Working Group, part of the W3C Rich Web Clients Activity in the W3C Interaction Domain. Introduction: " Web application technologies commonly apply same-origin restrictions to network requests. These restrictions prevent a (client-side) Web application running from one origin from obtaining data retrieved from another origin, and also limit the amount of unsafe HTTP requests that can be automatically launched toward destinations that differ from the running application's origin. In Web application technologies that follow this pattern, network requests typically use ambient authentication and session management information, including HTTP authentication and cookie information. This specification extends this model in several ways: (1) A resource can include an Access-Control-Allow-Origin header, with the origin of where the request originated from as the value, to allow access to the resource's contents. The user agent validates that the value and origin of where the request originated match. (2) User agents are enabled to discover whether a cross-origin resource is prepared to accept requests using a non-GET method from a given origin. This is again validated by the user agent. (3) Server-side applications are enabled to discover that an HTTP request was deemed a cross-origin request by the user agent, through the Origin header. This extension enables server-side applications to enforce limitations on the cross-origin requests that they are willing to service. This specification is a building block for other specifications, so-called hosting specifications, which will define the precise model by which this specification is used. Among others, such specifications are likely to include XMLHttpRequest Level 2, XBL 2.0, and HTML 5...


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

Headlines

Sponsors