Robin Cover

XML Daily Newslink. Thursday, 08 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
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.

http://ianfoster.typepad.com/blog/2008/05/saml-based-attr.html
See also the GridShib Project: http://gridshib.globus.org/

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

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.

http://www.incident.com/blog/?p=50
See also CAP references: http://xml.coverpages.org/emergencyManagement.html#oasis

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

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

http://xml.coverpages.org/OGC-buildingSMART-AECOO1.html
See also OGC Standards: http://www.opengeospatial.org/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.

http://automatedbuildings.com/news/may08/articles/novus/080426030303novus.htm
See also the OASIS Open Building Information Exchange (oBIX) TC: http://www.oasis-open.org/committees/obix/

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

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.

http://www.infoworld.com/article/08/05/08/sun-script_1.html

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

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.

http://www.w3.org/TR/2008/WD-curie-20080506
See also the W3C XHTML2 Working Group Home Page: http://www.w3.org/MarkUp/

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

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

http://xml.coverpages.org/emergencyManagement.html#draft-rosen-sipping-cap
See also the IETF Session Initiation Proposal Investigation (SIPPING) WG Charter: http://www.ietf.org/html.charters/sipping-charter.html

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

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.

http://www.infoq.com/news/2008/05/sparql-update-soa
See also the ESW Wiki for the Sparql Update Language: http://esw.w3.org/topic/SparqlUpdateLanguage

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

XML Daily Newslink and Cover Pages are sponsored by:

BEA Systems, Inc. http://www.bea.com
EDS http://www.eds.com
IBM Corporation http://www.ibm.com
Primeton http://www.primeton.com
SAP AG http://www.sap.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/

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

Back to newsletter list

Date:

From:

Subject:

XML Daily Newslink. Thursday, 08 May 2008