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

Headlines

Is ODF the New RTF or the New .DOC? Can It Be Both? Do We Need Either?
Build Server-Side Mashups with Geronimo and REST
The XDI RDF Model
XRI-as-Relative-URI Proposal
A Flash of Anti-Genius

Cover Pages

Public Review for OpenID Provider Authentication Policy Extension (PAPE) 1.0

Is ODF the New RTF or the New .DOC? Can It Be Both? Do We Need Either?
Rick Jelliffe, O'Reilly Technical

Rick Jelliffe Jon Bosak, who founded the XML and ODF efforts among many other achievements, recently wrote an article concerning the position of ODF, Open XML, and PDF... I think I can agree with much of what he says, though I would note Don't forget about HTML. Jon's awareness of the different capabilities of different formats, and the centrality of having a clear understanding of these, stimulated me to try to articulate something I have been thinking about for while: is ODF better considered a replacement for .DOC or .RTF, and can it be a substitute for both? And are there any bigger issues than this looming, that we should take stock of? [...] I suggest that perhaps the looming challenge for document standards is not in deciding or developing perfect formats, but in integrating the packaged world of documents with the fragmented world of web resources. Documents that can be websites. Page description files with external resources. Arbitrarily nestable documents. Web applications that are single files and editable as applications by word processors: in this vision, Open Office or MS Word (or perhaps MS Powerpoint) should be able to open up and edit a .WAR web archive file (or their successors.) image006.png Again, the centre requirement is the document packaging mechanism, enhanced to allow unpackaging and web service. The [referenced] diagram, though almost uselessly general, lists various components that are entirely common to both websites and XML-in-ZIP compound documents: why are we squabbling in such minute detail on solutions to XML-in-ZIP formats that do nothing to address this tectonic rift between documents and websites? Because we allow our expectations to be dictated by menu bars: something that currently has a Save As.. or Open menu item is real... It is obviously not an outlandish vision: there is piecemeal support for many parts already. ODF and OOXML's packaging mechanism each integrate into the MIME media content types system and have many connections with the W3C mini-formats (Dublin Core, MathML, etc.). Word supports blogging using Atom distribution. Some file system managers allow ZIP archives to be treated as if the were file systems. Synchronization and offline behaviour is a mainstream behaviour because of mobile and PDA systems. There are printers that support JPEG and SVG directly. Some word processors do have publish and save-as-website converters. The WWW's implicit REST approach encourages richer information bundles rather than stateful servers...

Build Server-Side Mashups with Geronimo and REST
J. Jeffrey Hanson, IBM developerWorks

Mashups are popular among site developers because of the ease with which data and content can be combined. This ease comes from the availability and ubiquity of dynamic and semantically rich technologies for the Web -- technologies such as XML, JavaScript Serialized Object Notation (JSON), Resource Description Framework (RDF), dynamic JavaScript, and Ajax. These and other technologies provide an unlimited degree of possibilities for creative content developers. Apache Geronimo is a Java EE platform you can use to build enterprise services and applications. Geronimo is designed around decoupled services and components to facilitate a very modular, manageable, and configurable deployment and execution environment. Mashups have gained popularity among site developers because of the possibilities presented and the ease with which data and content can be combined. This ease comes from the availability and ubiquity of dynamic and semantically rich technologies for the Web—technologies such as XML, JSON, RDF, dynamic JavaScript, and Ajax. This article discusses techniques for combining REST-style service invocations with Ajax-based clients and servers in a Java framework to retrieve location data for a given Twitter user. The location data is then used to retrieve latitude and longitude data from Google Maps, which are in turn applied using client-side Ajax techniques to create a Google Maps map dynamically applied to a mashup page.

The XDI RDF Model
Drummond Reed, Markus Sabadello, Paul Trevithick; OASIS Draft

This work-in-progress document from the OASIS XDI Technical Committee provides an overview and technical definition of the XDI RDF model. XDI (XRI Data Interchange) is an open standard data sharing format and protocol under development by the OASIS XDI Technical Committee. XDI is an application of XRI structured identifiers, specified by the OASIS XRI Technical Committee, to the problem of sharing, linking, and synchronizing data independent of any particular domain, application, or schema. The XDI TC, which began its work in 2004, originally developed a data model called the ATI (Authority/Type/Instance) model. In early 2007 a second model was developed based on the RDF graph model from the W3C Semantic Web activity. It is proposed that this XDI RDF model become the basis for the XDI 1.0 specifications now that the OASIS XRI Technical Committee has completed the final specification in the XRI 2.0 cycle (XRI Resolution 2.0 Committee Draft 03). The motivations for development of the XDI RDF data model were: (1) Simplicity. While the XDI ATI model was relatively simple, consisting of only eight elements and one attribute in the XML serialization, the XDI RDF model is even simpler, using only five elements and one attribute in the XML serialization. It is so simple that the compact X3 serialization format can be expressed in just six lines of core ABNF. (2) Full fidelity with the RDF graph model. Although the XDI ATI model was inspired by the core concepts of RDF, it did not strictly follow the RDF graph model. It permitted both data literals and data references to be associated with subject, predicate, and object nodes. With the XDI RDF model, a data literal may only appear as an XDI RDF object. (3) Additional relation types. The XDI ATI model included on two fundamental relation types—refs for equivalence and links for aggregation. The XDI RDF model adds two more fundamental relation types for representing inheritance and composition... Simplified human understanding. With the XDI RDF model, the XDI graph can be represented using the same (or simpler) notational formats as other RDF graphs, including a very simple notation called X3 (inspired by RDF N3 notation)... The first key XRI feature used by XDI, called cross-references, has been part of XRI syntax since XRI 1.0. As a language for structured identifiers, XRI has always needed the ability to encapsulate and describe other identifiers from other identifier syntaxes and namespaces very much the same way XML can encapsulate and 'tag' data from different native data sources. In XRI 2.0, this feature uses parentheses to syntactically encapsulate the cross-referenced identifier. It is vital to XDI RDF because it enables all any URI to be included in an XRI expressing an XDI RDF statement. This also enables conventional RDF documents to be expressed and addressed in XDI RDF...

See also: the Wiki

XRI-as-Relative-URI Proposal
Drummond Reed, Posting to WWW-TAG

"The OASIS XRI TC would like to thank the TAG and other members of this list for the extensive feedback they have provided on XRI 2.0 since early July. Proof that it has been productive has been the emergence of a new proposal for how XRIs can better fit with AWWW architecture. This proposal has received extensive discussion within the XRI TC and on the XRI TC mailing list over the last month, and has had an initial preview with the TAG. They found the proposal encouraging and suggested public discussion on this list as a next step. The proposal is written up on an XRI TC wiki page ['XRI-as-Relative-URI proposal']. I won't even attempt a one-sentence summary here as it would only duplicate the summary there, and the page already serves as a mini-FAQ for most of the questions it has generated. To those who have contributed to the XRI discussions here, and to anyone else interested in the topic of abstract identifiers (in AWWW lingo, identifiers of non-information resources that do not have direct representations, only descriptions), we are very interested in your feedback about this proposal..." [Wiki: "When the XRI Technical Committee was founded in 2003, it was assumed that the TC would fulfill its charter to develop a uniform abstract identifier syntax and resolution architecture by defining a new URI scheme. It was widely believed that this was the best way to ensure compatability with the Architecture of the World Wide Web (AWWW)... However as the Web has evolved, so has the W3C TAG's view of new URI schemes. The TAG now strongly discourages the use of new URI schemes whenever existing schemes, particularly the http: URI scheme, can be adapted to fulfill new resource identification requirements... The conclusion [for XRI] has been that, rather than define a new URI scheme, the goals of XRI architecture can also be met by (1) Formally defining XRI syntax as form of relative URI, (2) Defining bindings between this form of relative URI and base URIs in URI schemes where XRI syntax and semantics can add value... The XRI TC would love to hear from you with feedback on this proposal. Discussion is currently underway on the W3C TAG public mailing list, which is open to anyone to join. Look for threads with the tag '[XRI]'. You can also send feedback directly to the XRI TC chairs via the email addresses listed at the top of the XRI TC home page..."

A Flash of Anti-Genius
William Vambenepe's, Blog (IT Management in a Changing IT World)

"Just this week, I saw two emails that painfully illustrate what is maybe the single worst thing about the way Flash is used on many web sites: the lack of addressability. The first email was a request for help about finding a specific view on a Flash-based app... The answer came quickly, in the form of a screen capture of the Flash app with the multi-level menu open and pointed at the menu entry that produces the requested view... Look at the email that arrived the following day. [The author] wanted to advertise for rent an apartment he owns in the new One Rincon Hill tower in San Francisco. In order to provide a link to the floor plan, here is what he had to put in the email: Plan 5 -- see [URI] (Lower right 'Skip intro', then follow the link on Residences and Views -> Condominiums -> Tower One -> 1 Bedroom -> Unit 05)... This is a 'no Flash, no service' site. There is no alternative. Ironic for a tower in which 95% of occupants own an iPhone... Even more ironic is that fact that Flash is used on this site to navigate menus (usefulness: zero) and when you get to the floor map it's a plain static image... now, more than 15 years after TBL's invention, Flash-drunk nitwits are recreating the problem he solved and forcing people to again 'create small files that describe where to find information in a human-readable way'. When WS-Addressing decided to deprecate URLs, they at least provided a replacement (the EPR). What is the Flash equivalent going to be? Who wants to write the DARC (Distributable Addressing for Rich Clients) specification?"

Selected from the Cover Pages, by Robin Cover

Public Review for OpenID Provider Authentication Policy Extension (PAPE) 1.0

On behalf of members in the OpenID Provider Authentication Policy Extension (PAPE) Working Group, Mike Jones announced that the WG now recommends approval of PAPE Draft 7 as an OpenID Specification. The 60-day public review period extends through Sunday, December 21, 2008. The OpenID Provider Authentication Policy Extension (PAPE) specification, according to Jones, "enables an OpenID Relying Party to request that the OpenID Provider satisfy a set of policies specified by the RP when the OP logs the user in. And it likewise enables the OP to reply to the RP saying which of the policies it satisfied... One of these policies lets the RP request that the OP perform phishing-resistant authentication, the need for which has been discussed here and elsewhere. This extension to the OpenID Authentication protocol 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. This extension also 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 or multi-factor authentication method. This extension also provides a mechanism by which a Relying Party can request that the OpenID Provider communicate the levels of authentication used, as defined within one or more sets of requested custom Assurance Levels, and for the OpenID Provider to communicate the levels used. This extension is 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. While none of the information transmitted using this extension can be verified by the Relying Party using technology alone, this does not limit the utility of this extension. Because there is no trust model specified by OpenID, Relying Parties must decide for themselves which Providers are trustworthy; likewise, RPs can decide whether to trust authentication policy claims from such OpenID Providers as well.


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

Headlines

Cover Pages

Sponsors