Cover Pages: XML Daily Newslink: Thursday, 22 May 2008

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:
Sun Microsystems, Inc. http://sun.com

Headlines

Topic Maps Reference Model, ISO 13250-5 Final Committee Draft
W3C Last Call: Cascading Style Sheets (CSS) Snapshot 2007
Proposed Provider Authentication Policy Extension (PAPE) Working Group
Updated Working Draft: Progress Events 1.0
Opinion: XRIs Bad, URIs Good

Topic Maps Reference Model, ISO 13250-5 Final Committee Draft
Patrick Durusau, Steve Newcomb, Robert Barta (eds), ISO FCD

The ISO/IEC JTC 1/SC 34 Secretariat announced the public availability of "Topic Maps Reference Model 13250-5 FCD," released for comment and ballot. "The Topic Maps family of standards is designed to facilitate the gathering of all the information about a subject at a single location. The information about a subject includes its relationships to other subjects; such relationships may also be treated as subjects (subject-centric). ISO/IEC 13250-2 (TMDM, Topic Maps Data Model) provides a foundation for syntaxes and notations, such as those defined in ISO/IEC 13250-3 Topic Maps XML Syntax and ISO/IEC 13250-4 Topic Maps Canonicalization. Of necessity, the TMDM makes ontological commitments in terms of how particular subjects are identified (topics, associations, occurrences), what properties are required, the tests to be used to determine whether two or more proxies represent the same subject, and other matters. This Standard defines TMRM (Topic Maps Reference Model), which is more abstract and has fewer ontological commitments. Its purpose is to serve as a minimal, conceptual foundation for subject-centric data models such as the TMDM, and to supply ontologically neutral terminology for disclosing these. It defines what is required to enable the mapping of different subject-centric data models together to meet the overall goal of the Topic Maps standards, that each subject has a single location for all the information about it. TMRM also provides a formal foundation for related Topic Maps standards such as ISO/IEC 18048 Topic Maps Query Language (TMQL) and ISO/IEC 19756 Topic Maps Constraint Language (TMCL)."

W3C Last Call: Cascading Style Sheets (CSS) Snapshot 2007
Elika J. Etemad (ed), W3C Technical Report

W3C's Cascading Style Sheets (CSS) Working Group has published the Last Call Working Draft for "Cascading Style Sheets (CSS) Snapshot 2007." Comments are welcome through 09-June-2008. This document collects together into one definition all the specifications that together form the current state of Cascading Style Sheets (CSS). When the first CSS specification was published, all of CSS was contained in one document that defined CSS Level 1. CSS Level 2 was defined also by a single, multi-chapter document. However for CSS beyond Level 2, the CSS Working Group chose to adopt a modular approach, where each module defines a part of CSS, rather than to define a single monolithic specification. This breaks the specification into more manageable chunks and allows more immediate, incremental improvement to CSS. Since different CSS modules are at different levels of stability, the CSS Working Group has chosen to publish this profile to define the current scope and state of Cascading Style Sheets as of late 2007. This profile includes only specifications that we consider stable and for which we have enough implementation experience that we are sure of that stability. Note that this is not intended to be a CSS Desktop Browser Profile: inclusion in this profile is based on feature stability only and not on expected use or Web browser adoption. This profile defines CSS in its most complete form. Note also that although the WG does not anticipate significant changes to the specifications that form this snapshot, their inclusion does are not mean they are frozen. The Working Group will continue to address problems as they are found in these specs. Implementers should monitor www-style and/or the CSS Working Group Blog for any resulting changes, corrections, or clarifications. The primary audience is CSS implementors, not CSS authors, as this definition includes modules by specification stability, not Web browser adoption rate.

Proposed Provider Authentication Policy Extension (PAPE) Working Group
Staff, OpenID Foundation Announcement

A Charter Proposal was published for the formation of a new "Provider Authentication Policy Extension (PAPE)" Working Group. The goal is to produce a standard OpenID extension to the OpenID Authentication protocol that "provides a mechanism by which a Relying Party can request that particular authentication policies be applied by the OpenID Provider when authenticating an End User and provides a mechanism by which an OpenID Provider may inform a Relying Party which authentication policies were used." Thus a Relying Party can request that the End User authenticate, for example, using a phishing-resistant and/or multi-factor authentication method. WG Members would produce a revision of the PAPE 1.0 Draft 2 specification that clarifies its intent, while maintaining compatibility for existing Draft 2 implementations. Adding any support for communicating requests for or the use of specific authentication methods (as opposed to authentication policies) is explicitly out of scope. Anticipated audience or users of the work include implementers of OpenID Providers and Relying Parties—especially those interested in mitigating the phishing vulnerabilities of logging into OpenID providers with passwords. The "OpenID Provider Authentication Policy Extension 1.0" (Draft 2, October 2007) was not "intended to provide all information regarding the quality of an OpenID Authentication assertion. Rather, it is designed to be balanced with information the Relying Party already has with regard to the OpenID Provider and the level of trust it places in it. If additional information is needed about processes such as new End User enrollment on the OpenID Provider, such information should either be transmitted out-of-band or in other extensions such as OpenID Attribute Exchange. Other aspects (e.g., security characteristics, credential provisioning, etc) could be dealt with in the future, though End User privacy concerns must be kept in mind especially when discussing enrollment procedures." A vote by members of the OpenID Foundation to (dis)approved WG formation was scheduled for June 6-13, 2008.

See also: PAPE 1.0 Draft 2

Updated Working Draft: Progress Events 1.0
Charles McCathieNevile (ed), W3C Technical Report

Members of the W3C Web API Working Group have published a Working Draft for the "Progress Events 1.0" specification. The document describes event types that can be used for monitoring the progress of an operation. It is primarily intended for contexts such as data transfer operations specified by XMLHTTPRequest, or Media Access Events. A progress event occurs when the user agent makes progress in some data transfer operation, such as loading a resource from the web via XMLHttpRequest. Specifications which have a use case for these events should define when Progress events are dispatched. Scripts may use progress events in order to provide feedback on operations performed by an application. For example, anapplication uses the information in progress events emitted as an image loads in order to fill a progress bar as it receives progress events. Where the size of a download is unknown or there has been no progress yet there is simply a block moving back and forth within the progress bar to indicate that there is still some kind of activity... The mission of the W3C Web API Working Group is to develop specifications that enable improved client-side application development on the Web. This includes the development of programming interfaces to be made available in a Web client. The target platforms for this Working Group includes desktop and mobile browsers as well as many specialty, browser-like environments that use Web client technologies. The goal is to promote universal access both for devices and users, including those with special needs. Additionally, the Working Group has the goal to improve client-side application development through education, outreach and interoperability testing.

Opinion: XRIs Bad, URIs Good
Edd Dumbill, O'Reilly Opinion

A recent proclamation from the W3C's Technical Architecture Group recommends against using XRIs as identifiers. Hold up a second, XRIs? Unless you've been paying extra-special attention you won't have heard of these little critters much anyway. XRIs are 'Extensible Resource Identifiers', and are detailed in specifications that find their home at OASIS. XRIs are essentially fancy-pants URIs that support extra features such as decentralized allocation, federation and delegation. XRIs recently resurfaced on my agenda since reading the OpenID 2.0 specifications, whose service discovery documents include XML namespaces such as 'xri://$xrds' and 'xri://$xrd*($v*2.0)'. To the casual observer, it looks as though URIs have been given a work-over according to the old adage that nothing in computer science cannot be improved by adding a layer of indirection. XRIs have risen to common attention again through being factored into the OpenID specifications, due to the desire to keep supporting inames. The W3C's point of view is that everything XRIs attempt to do can already be done with URIs (or their internationalized incarnation, IRIs). I'm inclined to agree. There's still more than enough confusion as to what a URI means, without adding more machinery. Perhaps in 5 years we might have attained widespread knowledge about using URIs—we may think REST has 'made it', but its dissemination isn't that far and wide yet. The web I know and love is a collection of small pieces, loosely joined. XRIs by contrast are heavy metal. Call me old-fashioned, but the combination of URIs, DNS, and HTTP are all the web I can handle right now.

See also: the ballot announcement


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

Headlines

Sponsors