The Cover PagesThe OASIS Cover Pages: The Online Resource for Markup Language Technologies
SEARCH | ABOUT | INDEX | NEWS | CORE STANDARDS | TECHNOLOGY REPORTS | EVENTS | LIBRARY
SEARCH
Advanced Search
ABOUT
Site Map
CP RSS Channel
Contact Us
Sponsoring CP
About Our Sponsors

NEWS
Cover Stories
Articles & Papers
Press Releases

CORE STANDARDS
XML
SGML
Schemas
XSL/XSLT/XPath
XLink
XML Query
CSS
SVG

TECHNOLOGY REPORTS
XML Applications
General Apps
Government Apps
Academic Apps

EVENTS
LIBRARY
Introductions
FAQs
Bibliography
Technology and Society
Semantics
Tech Topics
Software
Related Standards
Historic
Last modified: May 29, 2009
XML Daily Newslink. Friday, 29 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



IETF Internet Draft: vCard Format Specification
Simon Perreault and Peter W. Resnick (eds), IETF Internet Draft

Members of the IETF vCard and CardDAV Working Group have published a revised Internet Draft for the vCard Format Specification. This 73-page Standards Track specification, if approved, will obsolete IETF RFCs 2425, 2426, and 4770, while updating RFC 2739. The "vCard Format Specification" defines the vCard data format for representing and exchanging a variety of information about an individual (e.g., formatted and structured name and delivery addresses, email address, multiple telephone numbers, photograph, logo, audio clips, etc.). Changes in version -07 of the specification include (for example): PREF is now bounded, and 100 is the maximum value (the "pref" parameter is optional, and is used to indicate that the corresponding instance of a property is preferred by the vCard author, and the integer between 1 and 100 quantifies the level of preferredness) Added the "emergency" RELATED type (viz., an emergency contact); Made GEO (used to specify information related to the global positioning of the object the vCard represents) a URI value; Added GEO and TZ (time zone)parameters to ADR, where geographical properties are concerned with information associated with geographical positions or regions associated with the object the vCard represents; Changed wording of "default" use of SOUND property; Completely reworked the date, time, and date-time grammars; Added the timestamp value type; REV (used to specify revision information about the current vCard) now has the timestamp value type; Rewrote the ABNF; ORG can now have a single level.

Electronic address books have become ubiquitous. Their increased presense on portable, connected devices as well as the diversity of platforms exchanging contact data call for a standard. The vCard format allows the capture and exchange of information normally stored within an address book or directory application. The text/vcard MIME content type contains contact information, typically pertaining to a single contact or group of contacts. Individual lines within vCard are delimited by the line break (see RFC 5322), which is a CRLF sequence (ASCII decimal 13, followed by ASCII decimal 10). Long logical lines of text can be split into a multiple-physical-line representation using the following folding technique. Content lines SHOULD be folded to a maximum width of 75 octets. Multi-octet characters MUST remain contiguous. The rationale for this folding process can be found in RFC 5322. A logical line MAY be continued on the next physical line anywhere between two characters by inserting a CRLF immediately followed by a single white space character (space, ASCII decimal 32, or horizontal tab, ASCII decimal 9). At least one character must be present on the folded line. Any sequence of CRLF followed immediately by a single white space character is ignored (removed) when processing the content type.

Note: As of May 2009, an Internet Draft specification vCard XML Schema was under development. This XML schema, expressed in the RELAX NG language, defines the XML schema of the vCard data format for representation vCard data. 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.

See also: the vCard XML Schema


WS-Federation Version 1.2 Approved as an OASIS Standard
Staff, OASIS Announcement

OASIS announced that the approved Committee Specification for Web Services Federation Language (WS-Federation) Version 1.2 balloted for consideration as an OASIS Standard has been voted affirmatively as a new standard. Edited by Marc Goodner (Microsoft) and Anthony Nadalin (IBM), this OASIS specification defines mechanisms to allow different security realms to federate, such that authorized access to resources managed in one realm can be provided to security principals whose identities are managed in other realms. While the final access control decision is enforced strictly by the realm that controls the resource, federation provides mechanisms that enable the decision to be based on the declaration (or brokering) of identity, attribute, authentication and authorization assertions between realms. The choice of mechanisms, in turn, is dependent upon trust relationships between the realms. While trust establishment is outside the scope of this document, the use of metadata to help automate the process is discussed. A general federation framework must be capable of integrating existing infrastructures into the federation without requiring major new infrastructure investments. This means that the types of security tokens and infrastructures can vary as can the attribute stores and discovery mechanisms. Additionally, the trust topologies, relationships, and mechanisms can also vary requiring the federation framework to support the resource's approach to trust rather than forcing the resource to change.

The federation framework defined in WS-Federation builds on WS-Security, WS-Trust, and the WS-* family of specifications providing a rich extensible mechanism for federation. The WS-Security and WS-Trust specification allow for different types of security tokens, infrastructures, and trust topologies. This specification uses these building blocks to define additional federation mechanisms that extend these specifications and leverage other WS-* specifications. The mechanisms defined in the WS-Federation specification can be used by Web service (SOAP) requestors as well as Web browser requestors. The Web service requestors are assumed to understand the WS-Security and WS-Trust mechanisms and be capable of interacting directly with Web service providers. The Web browser mechanisms describe how the WS-* messages (e.g. WS-Trust's RST and RSTR) are encoded in HTTP messages such that they can be passed between resources and Identity Provider (IP)/ Security Token Service (STS) parties by way of a Web browser client. This definition allows the full richness of WS-Trust, WS-Policy, and other WS-* mechanisms to be leveraged in Web browser environments. It is expected that WS-Policy and WS-SecurityPolicy (as well as extensions in this specification) are used to describe what aspects of the federation framework are required/supported by federation participants and that this information is used to determine the appropriate communication options. The assertions defined within this specification have been designed to work independently of a specific version of WS-Policy. At the time of the publication of this specification the versions of WS-Policy known to correctly compose with this specification are WS-Policy 1.2 and 1.5. Within this specification the use of the namespace prefix wsp refers generically to the WS-Policy namespace, not a specific version.

See also: the ballot


CMIS Proposal: Document Previews, Thumbnails, and Renditions
David Caruana and Ryan McVeigh (eds), OASIS Working Draft

Members of the OASIS CMIS Technical Committee have produced draft proposals for consideration of a mechanism to support document "renditions" in the CMIS specification. Excerpt from the Draft Version 0.3: "Some ECM repositories provide renditions where a client can get an alternative version of a document. This could apply to a preview case which would enable the client to preview the content of a document without needing to download the full content. Previews are generally reduced fidelity representations such as thumbnails. Renditions can take on any general form, such as a PDF version of a word document...

This proposal offers an optional extension to CMIS for allowing a client to gain access to document renditions... This proposal advocates describing document previews in the CMIS Domain Model. This provides a formal definition of a preview which may be mapped by each of the CMIS bindings... Requirements for the Model: (1) A document may support zero or more renditions, where: (a) the server is responsible for determining the number and types of renditions present for a given document; (b) the server is responsible for the availability of a document rendition, and a rendition may not be immediately available after checkin; (c) renditions can be related to one another—such as an ordered list; we should be able to express this model as part of the rendition metadata; (d) renditions are specific to the version of the document and may differ between document versions. (2) Each rendition consists of a content stream containing the alternative representation; (3) Each rendition consists of a content stream of a given mimetype. (4) Each rendition may have a descriptive label. (5) Each rendition is loosely identified by label and mimetype -- although uniqueness not enforced. (6) Each rendition may provide additional metadata such as sizing... The API must retrieve available renditions for a document, retrieve rendition descriptive label and additional metadata, and retrieve rendition content stream. The API should retrieve a document represented by rendition, but will not create renditions (assumption: the repository creates the rendition).

Domain Model: Previews are themselves Documents. They are associated to their original document via relationships of the 'preview' relationship type. This proposal does not impose any constraints on whether preview documents are filed in folders or unfiled... Web Services Binding, as proposed: No additional Web Service methods or adjustments to existing methods are required to support document previews, as getRelationships() and getContentStream() suffice. AtomPub Binding: As with the Web Service, the AtomPub binding does not strictly need enhancing to support document previews. However, the natural AtomPub use of links lends itself well to representing 'preview' relationships. For Atom Entries representing documents, each related preview is represented via the following link link rel="preview"...

See also: the JIRA issue


OASIS Content Management Interoperability Services (CMIS) Draft 0.62a
Al Brown and Ethan Gur-esh (eds), OASIS Working Draft

Members of the OASIS Content Management Interoperability Services (CMIS) Technical Committee have released a Draft Version 0.62a for the CMIS specification. The release package includes some 713 files in a ZIP archive of Schema materials, along with three principal prose documents.

"Content Management Interoperability Services — Domain Model Version 0.62a" (136 pages, edited by Ethan Gur-esh) supplies an abstract: "The Content Management Interoperability Services (CMIS) standard defines a domain model and set of bindings, such as Web Service and REST/Atom that can be used by applications to work with one or more Content Management repositories/systems. The CMIS interface is designed to be layered on top of existing Content Management systems and their existing programmatic interfaces. It is not intended to prescribe how specific features should be implemented within those CM systems, nor to exhaustively expose all of the CM system's capabilities through the CMIS interfaces. Rather, it is intended to define a generic/universal set of capabilities provided by a CM system and a set of services for working with those capabilities."

CMIS provides an interface for an application to access a Repository. To do so, CMIS specifies a core data model that defines the persistent information entities that are managed by the repository, and specifies a set of basic services that an application can use to access and manipulate these entities. This data model does not cover all the concepts that a full-function ECM repository typically supports. Specifically, transient entities (such as programming interface objects), administrative entities (such as user profiles), and extended concepts (such as compound or virtual document, work flow and business process, event and subscription) are not included. However, when an application connects to a CMIS service endpoint, the same endpoint may provide access to more than one CMIS repositories... An application shall use the CMIS 'Get Repositories' service (getRepositories) to obtain a list of repositories that are available at that endpoint. For each available repository, the Repository must return a Repository Name, a Repository Identity, and an URI. The Repository Identity must uniquely identify an available repository at this service endpoint. Both the repository name and the repository identity are opaque to CMIS. Aside from the 'Get Repositories' service, all other CMIS services are single-repository-scoped, and require a Repository Identity as an input parameter. In other words, except for the 'Get Repositories' service, multi-repository and inter-repository operations are not supported by CMIS.

"Content Management Interoperability Services Version 0.62a Part II — Web Services Binding" (edited by Al Brown and Ethan Gur-Esh, 75 pages) defines the Web Services based binding for CMIS: All services and operations defined in part I of the CMIS specification are presented in this SOAP 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. Section 3.0 defines the mapping between all relevant pieces of the domain model as described in Part I of the CMIS specification. 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 exactly the abstract services defined in the services section of Part I of the CMIS specification. The normative CMIS SOAP binding is defined by the WSDL and XSD as well as the details given here in this part of the CMIS specification except the examples.

"Content Management Interoperability Services Version 0.62a. Part II — ReSTful AtomPub Binding" (edited by Al Brown and Ethan Gur-Esh, 44 pages) defines a specification based on AtomPub that can be used by applications to work with one or more Content Management Repositories. It is expected that this binding will be leveraged to build applications such as: (1) Quick UI components on the components, e.g., Widgets and Mashups; (2) Consumed by feed-centric applications such as Yahoo pipes; (3) Content-centric applications close to the glass, e.g., Java/JSP, .NET, AJAX; (4) Content-centric rich Internet Applications, e.g. flex, air...


OWF Publishes Open Web Foundation Agreement Version 2
David Rudin (et al, eds), OWF Legal Affairs Committee Draft

Members of the Open Web Foundation (OWF) Legal Affairs Committee have released the text of Open Web Foundation Agreement — Committee Draft 2. This 'work-in-progress; document does not have the official endorsement of the Open Web Foundation and is only a committee-draft. The purpose of the Agreement is to initiate the conversation regarding the creation of an Open Web Foundation Final Specification Agreement. The document sets forth terms under which [participants in an applicable technical activity] make certain copyright and patent rights available for implementations of a specification, including Copyright Grant and Patent Non-Assert. In adddition, the Agreement includes a 'Good Faith Obligation' clause ("I agree that I have not and will not knowingly take any action for the purpose of circumventing my obligations under this Agreement").

As explained in the non-binding commentary portion, the draft OWF agreement makes necessary patents available under two mechanisms. "The first is a patent non-assert, which is intended to be a simple and clear way to assure that the broadest audience of developers and users working with commercial or open source software can implement specifications through a simplified method of sharing of technical assets, while recognizing the legitimacy of intellectual property. It is a way to reassure that audience that the specification can be used for free, easily, now and forever. The second mechanism is an agreement to make necessary patent claims available under reasonable and non-discriminatory terms without royalty (also known as RAND-z), which is a common approach taken by standards bodies. That license itself would be agreed upon between the patent owner and the party wishing to use the patent. We believe that the non-assert should be sufficient for most purposes, but included the RAND-z provision as an option for situations in which the non-assert may not be appropriate or valid. The RAND-z option is also intended to facilitate the potential transition of the specification to a formal standards body."

In an associated posting, David Rudin clarifies the nature of three changes in this draft: (1) Implementation-based Patent Grant: In the previous draft, the grant of patent claims was based on the extent to which an implementation conformed to the specification. Concerns that that language could imply that conformance could be measured against a third party conformance suite or some other criteria that was outside of the community's control. To address this, the current draft makes the grant contingent upon the implementation of the specification. In other words, this change is meant to clarify that that grant is based on inward looking criteria (was the spec implemented) rather than outward looking criteria (the spec conforming with something). (2) Derivative Works: This draft abandons the need for a new signoff for any new version of a specification and therefore allows the patent promise to flow with the derivative work. The goal here is to be functionally equivalent to making a normative reference but allow derivative works to actually carry over the text from the original spec... (3) Broader Defensive Suspension: This draft expands defensive suspension from the previous drafts two ways. First, defensive suspension now includes the termination of copyright grants. This will allow someone who is sued by a non-implementing patent holder to potentially have a copyright claim against the party asserting the patent. Second, the patent rights granted by ALL parties that have signed the agreement for a given specification will be automatically terminated against a party suing over the patent claims in an implementation. There is a carve out, however, for defensive lawsuits. In other words, if someone sues me over their necessary patents in my implementation of a specification, they will lose their patent rights they received from all the other signatories for that particular specification. If I defensively countersue against that party, however, I do not lose my rights from third parties since all I am doing is protecting myself.

Related patent non-assert language in the Google Wave Federation Protocol Patent License: "Subject to the terms and conditions of this License, Google and its affiliates hereby grant to you a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this License) patent license for patents necessarily infringed by implementation of this specification. If you institute patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the implementation of the specification constitutes direct or contributory patent infringement, then any patent licenses for the specification granted to you under this License shall terminate as of the date such litigation is filed."

See also: the Google Wave Federation Protocol Patent License


Widgets 1.0: Packaging and Configuration
Marcos Cáceres (ed), W3C Technical Report

W3C has published a revised version of the Widgets 1.0: Packaging and Configuration specification, updating the document of 2008-12-22. The document was produced by members of the Web Applications WG, part of the Rich Web Clients Activity in the W3C Interaction Domain. This specification is part of the Widgets 1.0 family of specifications, which together standardize widgets as a whole. It is expected that this document will progress along the W3C's Recommendation track. The Last Call period ends on 19-June-2009. This version reflects over of two years work addressing requirements #1 to #25 of the "Widgets 1.0: Requirements" document. The requirements were addressed and specified through extensive research, and via consultation with W3C members and the public via the Working Group's mailing lists (WAF archive, WebApps archive). The purpose of this Last Call is to give external interested parties a final opportunity to publicly comment on how widgets should be packaged and configured before the Working Group makes a call for implementations. The Working Group's goal is to make sure that vendor's requirements for packaging and configuration have been effectively addressed and clearly specified. The latest Editor's Draft of this document is available from the W3C's CVS repository, and is updated on a regular basis.

"Widgets 1.0: Packaging and Configuration" standardizes a packaging format for a class of software application known as a widget. Widgets are client-side applications that are authored using Web standards, but whose content can also be embedded into Web documents. The specification relies on PKWare's Zip specification as the archive format, XML as a configuration document format, and a series of steps that runtimes follow when processing and verifying various aspects of a package. The packaging format acts as a container for files used by a widget. The configuration document is an XML vocabulary that declares metadata and configuration parameters for a widget. The steps for processing a widget package describe the expected behavior and means of error handling for runtimes while processing the packaging format, configuration document, and other relevant files. This document also defines expected behavior for conformance checkers, which are tools that aid authors in verifying that Zip archives and configuration documents conform to this specification.

There is currently no formally standardized way to author, package, digitally sign or internationalize a widget package for distribution and deployment on the Web. In the widget space, although many successful widget user agents are now on the market, widgets built for one widget user agent are generally not able to run on any other widget user agent. This document lists the design goals and requirements that specifications need to address in order to standardize how widgets are authored/scripted, digitally signed, secured, packaged and deployed in a way that is device independent, follows W3C principles, and is as interoperable as possible with existing market-leading user agents and existing Web browsers.

W3C's Rich Web Clients Activity contains the work within W3C on Web Applications, which covers both APIs and formats. APIs are the assorted scripting methods that are used to build rich Web applications, mashups, Web 2.0 sites. Standardizing APIs improves interoperability and reduces site development costs. Formats covers certain markup languages, including Widgets for deploying small Web applications outside the browser, and XBL for skinning applications. Examples of applications built on rich Web clients include reservation systems, online shopping or auction sites, games, multimedia applications, calendars, maps, chat applications, weather displays, clocks, interactive design applications, stock tickers, office document and spreadsheet applications, currency converters, and data entry/display systems.

See also: the W3C Rich Web Clients Activity


Microsoft Bing: Much Better Than Expected
Rafe Needleman, CNET NEWS.com

Microsoft on Thursday took the wraps off Bing, the rebranded and rebuilt search engine formerly code-named Kumo, designed to replace Live Search. It's a solid improvement over the previous search product, and it beats Google in important areas. It will help Microsoft gain share in the search business. It's surprisingly competitive with Google. Bing isn't available to the public yet, but you won't have to wait long. Starting on June 1, 2009, some users will get Bing search results from Live Search. On June 3, we're told, Bing will be Microsoft's new default search. We got early access to the service... In search presentation, Bing wins. It uses technology from Powerset (a search technology company Microsoft acquired) to display refined versions of your query down the left side of the page. Bing also pop ups an excerpt of the text on a search result if you hover over it. This saves a lot of time if you're not quite sure if you want to follow a result.

When searching for product reviews, Google's search result pages were mostly better than Bing's—although, again, not by a lot. However, Bing also collates user and expert reviews on many products, and this gives you a great overview... And in some searches, Bing won on results outright. When searching for "Facebook sandberg" on Google, the top link was a story from 2008. On Bing, the top item was "News about facebook sandberg" with three sublinks to very recent articles. When searching for "Obama Supreme Court," Google did show news results, but the top link was a day-old story. Bing's was from 32 minutes ago. All search engines have their strengths, and many of Bing's lie in areas where Microsoft has its own content companies. For example, Microsoft owns the airfare prediction service Farecast, and it includes Farecast buying advice whenever you search for airplane travel. Bing also displays some medical data inside the search engine itself...

From the Microsoft announcement: "Microsoft Corp. today unveiled Bing, a new Decision Engine and consumer brand, providing customers with a first step in moving beyond search to help make faster, more informed decisions. Bing is specifically designed to build on the benefits of today's search engines but begins to move beyond this experience with a new approach to user experience and intuitive tools to help customers make better decisions, focusing initially on four key vertical areas: making a purchase decision, planning a trip, researching a health condition or finding a local business. The result of this new approach is an important beginning for a new and more powerful kind of search service, which Microsoft is calling a Decision Engine, designed to empower people to gain insight and knowledge from the Web, moving more quickly to important decisions. The new service, located at http://www.Bing.com, will begin to roll out over the coming days..."

See also: the Microsoft announcement


Google Bets Big on HTML 5: News from Google I/O
Tim O'Reilly, Radar Blog

"Never underestimate the web," says Google VP of Engineering Vic Gundotra in his keynote at Google I/O this morning. He goes on to tell the story of a meeting he remembers when he was VP of Platform Evangelism at Microsoft five years ago. "We believed that web apps would never rival desktop apps. There was this small company called Keyhole, which made this most fantastic geo-visualization software for Windows. This was the kind of software we always used to prove to ourselves that there were things that could never be done on the web." A few months later, Google acquired Keyhole, and shortly thereafter released Google Maps with satellite view. Now: "we're betting big on HTML 5." Vic pointed out that the rate of browser innovation is accelerating, with new browser releases nearly every other month. The slides show the progress towards the level of UI functionality found in desktop apps through adoption of HTML 5 features in browsers... While the entire HTML 5 standard is years or more from adoption, there are many powerful features available in browsers today. In fact, five key next-generation features are already available in the latest (sometimes experimental) browser builds from Firefox, Opera, Safari, and Google Chrome. Microsoft has announced that it will support HTML 5...

During his keynote, Vic was joined on stage by Jay Sullivan, VP of Mobile at Mozilla and Michael Abbot, the SVP in charge of application software and services at Palm. Both showed their own commitment to working with HTML 5. Jay expressed Mozilla's commitment to keeping the web open: "Anything should be hackable; anything should be scriptable. We need to get out of plugin prison." Javascript rendering in Firefox 3.5 is 10x faster than in Firefox 2, with support for video, offline storage, web workers, and geolocation. Michael showed how Palm's WebOS relies on HTML 5. "You as a developer don't need to leave your prior knowledge at the door to develop for the phone." He demonstrates the power of CSS transformations to provide UI effects; he shows how the calendar app is drawn with Canvas, how bookmarks and history are kept in an HTML 5 database. Michael emphasized the importance of standardization, but also suggested that we need new extensions to HTML 5, for example, to support events from the accelerometer in the phone. Palm has had to run out ahead of the standards in this area... If you're like me, you had no idea there was so much HTML 5 already in play... Support by four major browsers adds up to "rough consensus" in my book...


Sponsors

XML Daily Newslink and Cover Pages sponsored by:

IBM Corporationhttp://www.ibm.com
Microsoft Corporationhttp://www.microsoft.com
Oracle Corporationhttp://www.oracle.com
Primetonhttp://www.primeton.com
Sun Microsystems, Inc.http://sun.com

XML Daily Newslink: http://xml.coverpages.org/newsletter.html
Newsletter Archive: http://xml.coverpages.org/newsletterArchive.html
Newsletter subscribe: newsletter-subscribe@xml.coverpages.org
Newsletter unsubscribe: newsletter-unsubscribe@xml.coverpages.org
Newsletter help: newsletter-help@xml.coverpages.org
Cover Pages: http://xml.coverpages.org/



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

Sponsored By

IBM Corporation
ISIS Papyrus
Microsoft Corporation
Oracle Corporation

Primeton

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

 Newsletter Subscription
 Newsletter Archives
Globe Image

Document URI: http://xml.coverpages.org/newsletter/news2009-05-29.html  —  Legal stuff
Robin Cover, Editor: robin@oasis-open.org