The Open Grid Forum has announced the creation of OGF-Europe, funded
by the European Commission for Mobilizing and Integrating Communities
on Grid Standards & Best Practices Globally. OGF-Europe will capitalize
on European Commission investments in grid technologies by driving grid
adoption and innovation across Europe in research, government and
industry. The OGF-Europe project is aligned with OGF's global mission
of pervasive grid adoption through interoperable software standards.
Key deliverables include outreach seminars and workshops, adoption
challenges and recommendations reports; community surveys, best practice
reports and tutorials. OGF-Europe will also co-ordinate an Industry
Experts council to better understand how European enterprises are
dealing with issues surrounding interoperations and standardisation
and to engage them in the core work of OGF. OGF-Europe is led by
Barcelona Supercomputing Centre (BSC), technically co-ordinated by
OGF.eeig, and consists of eight other partners aiming to achieve its
ambitious goals. OGF is the international community dedicated to
accelerating grid adoption to enable business value and scientific
discovery by providing an open forum for grid innovation and developing
open standards for grid software interoperability.

Android is Google's foray into the handheld OS realm. It follows a path
trodden by—among others—Symbian's Quartz, the SavaJe operating
system, and J2ME. In fact, one of Android's stated goals is to overcome
some of J2ME's shortcomings. Whether or not Android succeeds, either at
that specific goal, or in general, remains to be seen. This article
addresses a specific question: What is it like to work with the Android
SDK? And to a lesser extent: What is under the Android hood? Peel away
Android's carapace, dig down to its marrow, and you'll find a Linux
kernel. Libraries are a layer above, a variety of frameworks above that,
and a final layer of applications sits on the top. The library layer is
home to code for entities such as media processors for playback and
recording of audio and video, the core of the Web browser, font rendering,
and the SQLite relational database engine... Hard-core developers will
be satisfied to work solely with the collection of command-line tools
that come with the SDK. For example, the activityCreator tool—which
is provided as a batch file for Windows, and as a Python script for Mac
and Linux users—will construct the framework for an Android Activity.
Executing activityCreator will build skeletal Java files, create the
Android project's required subdirectories, and build the necessary
manifest XML files. The tool also creates an Ant script file for compiling
the source and building the application... The Eclipse plug-in handles
compilation, conversion to dex, launching the emulator, and downloading
the application. Because writing Android code is writing Java code, the
editor behaves as it would were you constructing an ordinary Java
application. Resource files, which are written in XML, are easily managed
by XML editors already available in Eclipse. Debugging is likewise
supported from within Eclipse, and Android opens a debug perspective
that anyone already familiar with Eclipse will be comfortable with...
The Android SDK is a wonderful example of what can be done with open
source applications and tools. When the SDK's parts work, they work
reasonably well. However, at this point, would-be Android developers
must be willing to assist in debugging the development platform itself;
it's still pretty rough.

Testimony to the enduring debate about use of URIs to identify
(non-information) resources: David Booth announced a substantial
revision and expansion of his write-up on URI declarations "URI
Declaration Versus Use." Abstract: "A URI declaration permits
assertions about a URI's associated resource to be classified into
two groups: core assertions, whch are provided by the URI declaration,
and ancillary assertions, which are all others. This distinction
enables different parties to share a common understanding of the
associated resource (by accepting the core assertions) while making
different choices about which ancillary assertions to accept. This
paper defines these concepts and proposes some related best practices
and a Web architectural rule specifying how URIs for non-information
resources can be conveniently declared using existing hash or hashless
(303-redirect) URI mechanisms."

OASIS announced the publication of a Proposed Charter for an OASIS
Technical Committee to be named the "OASIS Unstructured Operation
Markup Language eXtended (UOML-X) TC." The purpose of this TC is to
carry on the existing OASIS UOML TC's goal of developing and maintaining
the XML-based operation interface standard for unstructured documents.
The Unstructured Operation Markup Language specification will define an
XML schema for universal document operations. The schema is suitable
for operating printable documents, including create, view, modify, and
query information, that can be printed on paper, e.g. books, magazine,
newspaper, office documents, maps, drawings, blueprints, but is not
restricted to these kinds of documents. There are several commercial
and free applications available based on the current draft of UOML, with
more currently under development. The UOML specification will be composed
of several parts. First part describes operations that should be used
to create, read, write, edit, display/print document. The other parts
describe operations for security control (include DRM), query, document
organizing etc., depend on the decision of this TC. Developers and users
of office application and document formatting specifications such as the
OASIS OpenDocument Format ("ODF") may also find UOML useful. However,
UOML addresses a different set of functions. The proposed UOML
specification will operate on layout-based formatting information,
rather than content-based formatting information (such as ODF). UOML
will limit its functions to abstracting data from paper form, and
defines an operation interface, rather than a file storage format. The
new TC will operate under the RF on RAND Mode under the OASIS IPR
Policy; the existing UOML TC operates under the RAND Mode of the OASIS
IPR Policy.

Or: "Why I'm not personally responsible for the completeness of the
web." I recently pointed a group of people to the Web Services Stack
Comparison page on the Apache wiki. This is a page that has been edited
by a bunch of people from different Web Services projects, but not me
personally. Its almost certainly not completely up-to-date—because
the projects change rapidly—but its a still a useful resource, and
being a wiki has the benefit that people from different projects can
update it with their own details. This might be the most accurate
available comparison—just because its self-edited. But the page isn't
complete: it also has no entries for Spring Web Services, ZSI, SOAP4R,
PHP5, or a host of other Web Services stacks. It doesn't have entries
for the WSO2 stacks either: WSF/C, WSF/PHP, WSF/Ruby, etc. Why am I
telling you this? Because someone took offense at my referencing this
incomplete page. So guess what? I suggested they or someone from CXF
updated it. Yes: its a wiki! That's how they work. If you look at
the edit history for this page you will see that people from Apache,
Sun, Oracle and elsewhere have all added their own details. The wiki
culture is very similar to the Open Source culture. If you want
something done, just do it. Its called a "do-ocracy" - the power is
with the people who actually write the code, do the work and make the
changes. Its probably the biggest shock to people in traditional
hierarchical organizations.

Members of the SIP for Instant Messaging and Presence Leveraging
Extensions (SIMPLE) Working Group have released an initial Internet Draft
for "Optimizing Federated Presence with View Sharing." Presence
federation refers to the exchange of presence information between
systems. One of the primary challenges in presence federation is scale.
With a large number of watchers in one domain obtaining presence for
many presentities in another, the amount of notification traffic is
large. This document describes an extension to the Session Initiation
Protocol (SIP) event framework, called view sharing. View sharing can
substantially reduce the amount of traffic, but requires a certain
level of trust between domains. View sharing allows the amount of
presence traffic between domains to achieve the theoretical lower bound
on information exchange in any presence system. The key idea with view
sharing is that when there are many watchers in a domain to a single
presentity in another domain, each of which is actually going to get
the exact same presence document, the domain of the watchers extends a
single subscription to the domain of the presentity, and the domain of
the presentity sends a single copy of the presence document back to the
domain of the watcher. In the case of a pair of large providers that
are peering with each other, this mechanism can result in a significant
savings. The ACL document informs a watching domain of the set of views
that can be received by that domain, and associates specific watchers
with specific views. An ACL document is an XML document that must be
well-formed and must be valid according to schemas, including extension
schemas, available to the validater and applicable to the XML document
(see XML Schemas in Section 5.5). ACL documents must be based on XML 1.0
and must be encoded using UTF-8. The SIMPLE WG was chatered to develop
an architecture for the implementation of a traditional buddylist-based
instant messaging and presence application with SIP. Included might be
new mechanisms for message confirmation delivery, indications for when
a party is in the process of typing a message, secure buddylist
manipulation operations, and the extension of the CPIM presence format
to describe typical IM states.

The Center for E-Commerce Infrastructure Development (CECID) at the
University of Hong Kong (HKU) has contributed Hermes Messaging Gateway
v2.0 (H2O) testing server for free to facilitate users to conduct
self-service testing after its installation. The Hermes Messaging Gateway
was developed as a platform for execution of common public standards,
like ebMS and AS2, to deliver a secure and reliable information transfer.
H2O operates as a Java web application. The ebMS and AS2 messaging
capabilities are operated by the corresponding plug-in, written according
to the H2O SPA specification. The messaging operation requires a database
with JDBC connectivity in keeping track of the messaging status. H2O has
open endpoints, and the enterprise backend applications can invoke H2O's
Web Services for message delivery. The message delivery can be secured
by using SSL or e-certificates, which conforms the public standards.
Since its release at CECID open-source community website in June 2007,
H2O has been downloaded and adopted by developers and users from over
60 economies around the world. Overwhelming responses and valuable
feedback are received daily via a mailing list and the community website,
in which some users reported that they experienced difficulties in
setting up the appropriate configuration during installation, and
finding partners for testing. In response to these comments related to
H2O installation, a testing server which serves as a virtual testing
machine is being setup at the community website to facilitate users to
troubleshoot installation problems and conduct self-service testing on
network connectivity to the Internet and message exchange functions. The
H2O testing server (a.k.a. Swallow) is a web-based platform for testing
messaging functionality of any client installed with H2O. It acts as a
standardized, user-friendly, and comprehensive testing suite for users
to test and learn how to use H2O practically. At Swallow, a user
interface is provided to create an interoperability profile. After
setting up, users can send their testing messages from their message
gateway to Swallow. In turn, Swallow will send responses back to the
users' message gateway, notifying them the message status and reporting
error messages if any. All these network data is captured and displayed
at Swallow's web interface for ease of monitoring the message
connectivity. In short, Swallow helps users to install H2O more
effectively and provides an Internet-based host to test their H2O
deployment in a holistic way.