password
username
Sponsored by CakeMail, an email marketing software.
Newsletter preview


XML Daily Newslink. Thursday, 22 May 2008
A Cover Pages Publication http://xml.coverpages.org/
Provided by OASIS http://www.oasis-open.org
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)."

http://xml.coverpages.org/topicMaps.html#TM-ReferenceModel-200805
See also ISO 13250 Part 1, Overview and Basic Concepts: http://xml.coverpages.org/topicMaps.html#TM-Overview-200805

----------------------------------------------------------------------

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.

http://www.w3.org/TR/2008/WD-css-beijing-20080516/
See also the W3C Web Style Sheets home page: http://www.w3.org/Style/

----------------------------------------------------------------------

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."

http://openid.net/pipermail/specs/2008-May/002323.html
See also PAPE 1.0 Draft 2: http://openid.net/specs/openid-provider-authentication-policy-extension-1_0-02.html

----------------------------------------------------------------------

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.

http://www.w3.org/TR/2008/WD-progress-events-20080521/
Seee also the W3C Web API Working Group: http://www.w3.org/2006/webapi/

----------------------------------------------------------------------

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.

http://www.oreillynet.com/xml/blog/2008/05/xris_bad_uris_good.html
See also the ballot announcement: http://xml.coverpages.org/newsletter/news2008-05-01.html#cite7

----------------------------------------------------------------------

XML Daily Newslink and Cover Pages are sponsored by:

BEA Systems, Inc. http://www.bea.com
IBM Corporation http://www.ibm.com
Primeton http://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 ***: newsletter-***@xml.coverpages.org
Newsletter help: newsletter-help@xml.coverpages.org
Cover Pages: http://xml.coverpages.org/

----------------------------------------------------------------------