Cover Pages: XML Daily Newslink: Thursday, 08 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:
IBM Corporation http://www.ibm.com

Headlines

SAML-Based Attributes for Globus Grids
The 'User Experience' of Warnings in the Emergency Alert System (EAS)
OGC and buildingSMART Alliance Issue CFP/RFQ for AECOO-Phase 1 Testbed
Automated Buildings: Beyond Open Systems
Sun Defends JavaFX Script
W3C Last Call: CURIE Syntax 1.0, A Syntax for Expressing Compact URIs
Session Initiation Protocol (SIP) Event Package for the Common Alerting Protocol (CAP)
SPARQL Update to Complete RESTful SOA Scenario

SAML-Based Attributes for Globus Grids
Ian Foster, Blog

The GridShib Project has announced the release of GridShib for Globus Toolkit v0.6.0. This is an exciting development, as GridShib software allows for powerful new authorization architectures in which access control decisions are made based on attributes obtained from many different sources... This release culminates a 20-month effort to bring SAML-based attribute push to X.509-based Grids. GridShib for Globus Toolkit (GT) is an implementation of a Grid Service Provider, an entity much like a SAML Service Provider but for Grids. A Grid Service Provider consumes X.509-bound SAML tokens, a new type of security token that enables attributed-based authorization in X.509-based Grids. A major advance in this version of GridShib for GT is support for the TeraGrid Science Gateway use case where an intermediary makes a grid request on behalf of a browser user. The Gateway binds a SAML token to an X.509 proxy certificate and makes a request to a gridshib-enabled web service. On the service side, GridShib for GT consumes the SAML token and makes an access control decision based on the security information in the token. As a SAML-consuming software component, GridShib for GT complements the previously released GridShib SAML Tools and GridShib Certification Authority (CA), which are SAML-producing software components. These three components together enable attribute-based authorization in X.509-based Grids. The Quick Start document provides step-by-step instructions that show how to use GridShib for GT v0.6, GridShib SAML Tools v0.3, and GridShib CA v0.5.1 together on Windows and UNIX systems.

See also: the GridShib Project

The 'User Experience' of Warnings in the Emergency Alert System (EAS)
Art Botterell, Blog

"In the runup to the May 19, 2008 Emergency Alert System (EAS) Showdown [Summit] in Washington, DC, most of the discussion has focused on the nuts and bolts of moving the nation's broadcast alerts across digital networks based on CAP. But CAP only defines the information 'payload' of a warning. It doesn't specify how that information should be presented over HD radio, digital TV, computers, PDAs, digital signage or any of our various other windows into the infosphere. This is going to become a crucial question in the very near future, I think. As digitization drives broadcast content onto ever more diverse platforms we're going to need to give these presentation/user interface issues as much attention as we have to transport/relay-network design. We may want to develop some common elements—consistent visual, aural, even tactile (e.g., portable device vibrator cadences) cues that one might almost call 'branding elements'—to ensure that emergency alerts have a degree of consistency across all media. Otherwise we risk letting diversity deteriorate into confusion. The Australians have made an interesting foray in that direction with their Standard Emergency Warning Signal (SEWS) basically a standard 'sounder' that can be used consistently over broadcast, wireless, wireline and even acoustical (siren and public address) delivery systems. However they haven't tried yet to set a comparable standard in the visual or other domains. Last year the FCC's cellular alerting advisory committee (the CMSAAC) took a few first steps toward designing a consistent user experience for a basic text-messaging interface... The Common Alerting Protocol (CAP) provides a rich standard data payload that can be presented—hopefully consistently—over all media, broadcast and otherwise. But the details of how best to present that richer message are still to be determined and require immediate skilled attention." Note: one of the panels at the FCC Public Safety and Homeland Security Bureau Emergency Alert System (EAS) will examine next generation technologies and look at how to ensure compatibility between federal implementation of the Common Alert Protocol (CAP) and state government operations.

See also: CAP references

OGC and buildingSMART Alliance Issue CFP/RFQ for AECOO-Phase 1 Testbed
Staff, OGC Announcement

The buildingSMART alliance, the Open Geospatial Consortium, Inc. (OGC) and Sponsors of the AECOO (Architecture, Engineering, Construction, Owner and Operator) Testbed have today issued a Request for Quotation (RFQ) and Call for Participation (CFP) for the AECOO-Phase 1 Testbed. The testbed aims to foster business transformation as defined in the United States National Building Information Modeling Standard, Part 1 (NBIMS) with technology for interoperability involving intelligent building models with 3D geometric capabilities. Business and communications, quantity take-off for cost estimating, and energy analysis are considered as they relate to planning and design for a capital facility. These three topic areas were selected by the Sponsors to focus attention on defining workable information solutions and services for information visualization and sharing... All organizations and individuals with expertise in the building information management field are encouraged to review and respond to the RFQ / CFP. Limited cost-sharing funding is available to help offset engineering costs incurred by participants in support of this effort. The buildingSMART alliance and OGC decided that OGC's Interoperability Program is the right mechanism to encourage broad international participation in solving well-defined sets of AECOO community problems; facilitating cooperation among AECOO standards bodies; and achieving results no group could achieve alone... The AECOO Testbed is an Interoperability Initiative that features a global, hands-on and collaborative rapid prototyping program designed to develop and deliver proven candidate standards into OGC's, NBIM's and buildingSMART International's specification programs where they are formalized for release as open standards... RFQ Annex A (Management and Business Overview; Work Breakdown Structure and Work Items) and Annex B ( Testbed Architecture) reference several baseline XML standards relevant to the Testbed. The initiative is based upon principles of 'Open Standardization' -- [being] "the reason for the success of the Internet, the World Wide Web, e-Commerce, and the wireless revolution." The reason is simple: our world is going through a communications revolution on top of a computing revolution. In the context of this OGC initiative, Open standardization means 'agreeing on a common definitions of terms and names, attributes and properties of information.' At the fundamental levels this type of open standardization has been developed by: (1) buildingSMART International: IFC and IFD; (2) Associated General Contractors with buildingSMART alliance: AGCxml; (3) International Code Council: SmartCodes; (4) Construction Specification Institute: OmniClass... Open standardization also means agreeing on common means for communication — the actions of 'transmitting or exchanging through a common system of symbols, signs or behavior concerning that information and how it needs to be delivered, presented or made capable'.

See also: OGC Standards

Automated Buildings: Beyond Open Systems
Anno Scholten, AutomatedBuildings.com

Open systems in building automation have come a long way. When I first became involved in building control systems many, many years ago, open protocol systems were well established. Control components such as thermostats, damper actuators, valve actuators, humidistats, etc were not only interoperable but fully interchangeable from one manufacturer to another... Open systems are truly successful. Market demand is now at an all time high. Most control system manufacturers can now provide BACnet, LON and Tridium web solutions, and most are working on WS/XML oBIX solutions. Open systems' success has been due to the hard work and dedication of many people in this industry. I'm sure we all remember the long hours put in by the developer community at events like BACnet Plug-Fests or LonMark Interoperability meetings to show that the technology really worked. Customers, sales and marketing people presented case study after case study of successful open system implementations at BuilConn, RealComm and other conferences. System integrators and the engineering community invested significantly in training on open system technologies. And finally, the hard work that Standards bodies such as LonMark, BTL, and OASIS have provided guarantees that we don't wander from the path. As a community, we should be proud of our open systems accomplishments. The question now becomes, where do we go next? I believe we can take one more page from the Telecommunication/IT, industry's history book to help answer this... Clearly open source is in our future. However, just as open source telephone handsets are unrealistic, I don't expect open source thermostats and controllers. What I do see is an open source development platform that can provide the infrastructure for powerful open solutions to our open systems. Our industry has many very smart, very experienced people who could release the power of open systems with an open source platform. Today, our ability to develop applications on top of BAS systems is limited by the small number of gateway technologies available and no common development platform. Open source is a natural next step.

Sun Defends JavaFX Script
Paul Krill, InfoWorld

In a world where the list of scripting languages for application development seems endless, is Sun's JavaFX Script one too many? This question was raised during the JavaOne conference in San Francisco, with an attendee wondering why Sun needed to have its own scripting variant. JavaFX Script is part of Sun's JavaFX rich Internet application platform, first announced a year ago but being filled out with product deliverables this year. With JavaFX Script, Sun is offering up a scripting language very similar to what already was available, argued developer Angsuman Chakraborty, CEO of Taragana. It is hard for developers to learn another language, Chakraborty said. "I don't think they need another language," Chakraborty said in an interview after first airing his views during a session with Sun officials. "It is an idiotic exercise, to put it bluntly. There is Groovy, there is JavaScript. All these languages are good enough and they can be molded into solving the needs of JavaFX." But Sun CTO Bob Brewin emphasized in an interview that JavaFX Script features a new set of capabilities such as allowing development of applications that can be moved outside the browser. JavaFX Script also is designed for content authors, not necessarily developers alone. JavaFX enables development of applications that can run on phones, the browser, and the desktop and this requires another language besides JavaScript, he said. An early-access release of JavaFX Script is to be released in July as part of a JavaFX software development kit... Brewin also filled in details about Sun's cloud services effort, called Project Hydrazine. It is to feature an infrastructure enabling developers to run services on the Web such as mapping, location, calendaring, and e-mail services. Due next year, Hydrazine is to be part of Sun's network.com grid infrastructure. Also part of Hydrazine is Project Insight, which will measure who is visiting Web sites. Developers will be able to find who is using their service and perhaps could deliver targeted advertising. Hydrazine combines attributes offered in Microsoft's Live Mesh data folder-sharing service, the Amazon Elastic Compute Cloud Web-based service and Google Analytics.

W3C Last Call: CURIE Syntax 1.0, A Syntax for Expressing Compact URIs
Mark Birbeck and Shane McCarron (eds), W3C Technical Report

W3C announced that the XHTML2 Working Group has published a Last Call Working Draft for the "CURIE Syntax 1.0" specification. The Last Call period for this document extends through 10-June-2008. Originally the document was based upon work done in the definition of XHTML 2, and work done by the RDF-in-HTML Task Force, a joint task force of the Semantic Web Best Practices and Deployment Working Group and XHTML 2 Working Group. The specification outlines a syntax for expressing URIs in a generic, abbreviated syntax (viz., a "Compact URI"). The specification targets language designers who need a mechanism to permit the use of extensible value collections. Any language designer considering the use of QNames in attribute values should consider instead using CURIEs, since CURIEs are designed for this purpose, while QNames are not. CURIEs can be used in exactly the same syntactic way QNames have been used in attribute values, with the modification that the format of the strings after the colon is looser. In all cases a parsed CURIE will produce an IRI. However, the process of evaluating involves replacing the CURIE with a concatenation of the value represented by the prefix and the part after the colon (the reference)... More and more languages need a mechanism to permit the use of extensible value collections. These are primarily found in XML attribute values, but also found in other, similar spaces in non-XML languages—e.g., SPARQL. Typically such extension mechanisms utilize the concept of scoping, where values are created within a unique scope, and that value space is managed by the group that defines it. Using such a mechanism allows independent organizations to define values without the risk of collision. At the same time, language designers are trying to ensure that their languages mesh smoothly into the semantic web. Since the basis of the semantic web is the notion that meaning can be derived through the relationship among resources, these extension mechanisms need a ready way of mapping their scoped values to resources (via URIs). In many cases, language designers are attempting to use QNames for this extension mechanism. QNames do permit independent management of the value space, and can map the values to a resource. Unfortunately, QNames are unsuitable in most cases because:: (1) they are NOT intended for use in attribute values, and (2) the syntax of QNames is overly-restrictive and does not allow all possible URIs to be expressed. The CURIE Syntax specification addresses the problem by creating a new data type whose purpose is specifically to allow for the definition of scoped values that map to URIs in exactly this way.

Session Initiation Protocol (SIP) Event Package for the Common Alerting Protocol (CAP)
Brian Rosen, Henning Schulzrinne, Hannes Tschofenig (eds.)

"The Common Alerting Protocol (CAP) is an XML document format for exchanging emergency alerts and public warnings. This document allows CAP documents to be distributed via the event notification mechanism available with the Session Initiation Protocol (SIP). RFC 3265 Session Initiation Protocol (SIP)-Specific Event Notification defines a SIP extension for subscribing to remote nodes and receiving notifications of changes (events) in their states. It leaves the definition of many aspects of these events to concrete extensions, known as event packages. This document defines such an event package: 'common-alerting-protocol'. Additionally, RFC 3903 Session Initiation Protocol (SIP) Extension for Event State Publication defines an extension that allows SIP User Agents to publish event state. According to RFC 3903, any event package intended to be used in conjunction with the SIP PUBLISH method has to include a considerations section... We define a new event package: 'common-alerting-protocol'. Event Publication Agents (EPA) use PUBLISH requests to inform an Event State Compositor (ESC) of changes in the common-alerting-protocol event package. Acting as a notifier, the ESC notifies subscribers about emergency alerts and public warnings... All subscribers and notifiers of the 'common-alerting-protocol' event package must support the 'application/common-alerting-protocol+xml' data format. The SUBSCRIBE request may contain an Accept header field. If no such header field is present, it has a default value of 'application/common-alerting-protocol+xml'—assuming that the Event header field contains a value of 'common-alerting-protocol'. If the Accept header field is present, it must include the media/MIME type 'application/common-alerting-protocol+xml'... This memo also therefore registers the 'application/common-alerting-protocol+xml' MIME type..."

SPARQL Update to Complete RESTful SOA Scenario
Thomas Bandholtz, InfoQueue

The LinkingOpenData Community Project has accomplished a global RESTful SOA scenario giving access to over two billion interlinked statements (RDF triples) from some 50 distributed providers such as DBpedia, Geonames, MusicBrainz, WordNet, the DBLP bibliography, or the 2000 U.S. Census. All this data is published in the Resource Description Framework (RDF) format. Each data set is structured as a named graph which can be accessed by a "Cool URI", using a simple HTTP GET. A detailled tutorial for contributors can be found in "How to Publish Linked Data on the Web." As datasets are widely interlinked between different sources, all this makes a large (if not huge) machine readable Web. If the provider also implements a SPARQL endpoint, may be using RDBMS-based tools such as D2R Server, clients may use the powerful SPARQL Query Language for RDF against the data. Even humans can get an impression using an RDF Browser such as the Tabulator Firefox add-on. The latest talk about LinkedData highlights more sophisticated application patterns like domain-specific LinkedData mashups, mobile geospatial entry-points, semantic search engines, data fusion, aggregation and drill down tools, which will certainly appear on the scene soon. However, there one serious limitation so far: this stunning network provides read access only. Currently this is addressed by the upcoming SPARQL Update language. While SPARQL Query has been developed by the W3C RDF Data Access Working Group since 2004 and finally came to W3C Recommendation in January this year, several issues had to be postponed, among them aggregate functions, and the update language. Recently Andy Seaborne (well-known Jena developer) and Geetha Manjunath, both from HP, published version 5 of a language for updating RDF graphs, (also known as "SPARUL"), which may push this topic forward.


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