|
XML and Web Services In The News - 2 January 2007
Provided by OASIS |
Edited by Robin Cover
This issue of XML Daily Newslink is sponsored by IBM Corporation
HEADLINES:
.
Five Disruptive Technologies to Watch in 2007
David Strom, InformationWeek
2007 will be the year when a host of hot technologies which have been
percolating around the mainstream rise high on the radar screens of
CIOs and IT managers. This article looks at five of the more significant,
including: RFID, Web Services, Advanced Graphics Processing, Server
Virtualization, and Mobile Security. After years of promise, Wal-Mart
and the Defense Department are among the organizations which have moved
RFID into the mainstream, using the technology to track everything from
pill bottles to palettes to people. As more vendors get on board, there
are some solid enterprise integration efforts developing back-end,
supply-chain, and inventory systems that can deliver real productivity
benefits to savvy enterprises... In 2006, we saw more buzzwords
describing the "Webification" of the enterprise. Software-as-a-service
(SaaS), mashups, Web 2.0, RSS feeds, Wikis, blogs, the rewritable Web,
social networking spaces, group chat rooms — no matter which aspect
you're talking about, clearly something new is happening here. The trick
is paying attention, because the Web services movement is producing
better and more capable enterprise class applications, which can be
deployed in a fraction of the time that more traditional apps took...
In the coming year, we'll see two forces changing the nature of graphics
in the enterprise: greater use of 3-D and the use of graphics processors
for computation. Operating systems themselves are using three-dimensional
elements as part of their basic tasks, and more applications are making
use of 3-D.
The application/atom+xml Type Parameter
James Snell (ed), IETF Internet Draft
An initial (version -00) public working draft has been released by
members of the IETF atompub Working Group for an "application/atom+xml
Type Parameter." The Atom Syndication Format (IETF RFC 4287) defines
two types of documents that can be identified using the
'application/atom+xml' media type. Implementation experience has
demonstrated, however, that Atom Feed and Entry Documents can have
different processing models and there are situations where they need
to be differentiated. A new optional parameter may be used to
differentiate the two types of Atom documents. The I-D defines a new
"type" parameter for use with the 'application/atom+xml' media type,
where type = "entry" / "feed". Neither the parameter name nor its
value are case sensitive. The value 'entry' indicates that the media
type identifies an Atom Entry Document. The root element of the document
must be atom:entry. The value 'feed' indicates that the media type
identifies an Atom Feed Document. The root element of the document
must be atom:feed. If not specified, the type is assumed to be
unspecified, requiring Atom processors to examine the root element to
determine the type of Atom document. New specifications may require
that the type parameter be used to identify the Atom Document type.
Producers of Atom Entry Documents should use the type parameter
regardless of whether or not it is required. Producers of Atom Feed
Documents MAY use the parameter. Atom processors that do not recognize
the 'type' parameter must ignore its value and examine the root element
to determine the document type.
See also: Atom references
oBIX Becomes an Approved OASIS Committee Specification
Ken Sinclair, AutomatedBuildings.com
This article is based upon an interview with Toby Considine (Technology
Officer, Facility Services, University of North Carolina, Chapel Hill),
who serves as co-chair of the OASIS Open Building Information Exchange
(oBIX) TC. Considine: "The committee still has more work to do. What we
have now is a good first step. oBIX provides a generic framework for
interacting with remote control systems. The committee has a few
organizational hurdles to overcome before we can move to become what
is called an OASIS standard. On the functional level, oBIX needs to
become more abstract and more Enterprise-centric. The initial reference
implementation is based upon the REST architectural standard. REST was
chosen because the experienced controls programmer will feel right at
home with REST. A controls-system developer will be able to begin
programming REST-based applications with only the shallowest of learning
curves. oBIX remains, however, a Control Protocol for Control System
Developers and Control System Integrators. The guys in the Enterprise
data center are still at a loss as to how to pull information out of
control systems. These people have their own hard jobs to do. They do
not want to learn how the HVAC systems are put together, anymore than
I want to know how carburetion decisions are made in my car. We need
to make it easier for them. We need to begin to standardize the
implementations for oBIX. We have discussed creating an oBIX
Implementation Committee. Many OASIS standards have an implementation
committee to define reference implementations and guide development.
We will be looking for OASIS members interested in that effort in the
new year. We are also starting to consider the roadmap to the next
version. I hope that with the low-level, control-oriented work done,
we can better align ourselves with the work of ASHRAE which will need
to build the same abstractions atop BACNET. This is an important task,
important to the development of new models for long-term sustainable
building operation. We will, of course, continue to share concerns
with the NBIMS committees coalescing around BuildingSmart, especially
COBIE, with the Open Geospatial Consortium, and with the GridWise
Architectural Council." [Ed Note: the article contains a typographic
error: oBIX is a Committee Specification, not an "OASIS Committee
Standard."]
See also: the PR
Mapping of TEI to CIDOC-CRM
Oyvind Eide and Christian-Emil Ore, TEI-Ontology-SIG List Announcement
Members of the Text Encoding Initiative (TEI) Ontology SIG have
published an initial draft of "Mapping of TEI to CIDOC-CRM." The CIDOC
Conceptual Reference Model (CRM) provides definitions and a formal
structure for describing the implicit and explicit concepts and
relationships used in cultural heritage documentation. The CIDOC CRM
is the culmination of over 10 years work by the CIDOC Documentation
Standards Working Group and CIDOC CRM SIG which are working groups of
CIDOC. The CIDOC CRM was accepted as working draft by ISO/TC46/SC4/WG9
in September 2000. As of 9/12/2006 it became an official ISO standard,
ISO 21127:2006. The CIDOC CRM is intended to promote a shared
understanding of cultural heritage information by providing a common
and extensible semantic framework that any cultural heritage information
can be mapped to. It is intended to be a common language for domain
experts and implementers to formulate requirements for information
systems and to serve as a guide for good practice of conceptual modeling.
In this way, it can provide the "semantic glue" needed to mediate
between different sources of cultural heritage information, such as
that published by museums, libraries and archives. The CRM is a domain
ontology in the sense used in computer science. It has been expressed
as an object-oriented semantic model, in the hope that this formulation
will be comprehensible to both documentation experts and information
scientists alike, while at the same time being readily converted to
machine-readable formats such as RDF Schema, KIF, DAML+OIL, OWL, STEP,
etc. It can be implemented in any Relational or objectoriented schema.
CRM instances can also be encoded in RDF, XML, DAML+OIL, OWL and others.
Although the definition of the CRM provided here is complete, it is an
intentionally compact and concise presentation of the CRM's 81 classes
and 132 unique properties. The mappings to TEI cover events, time
appelations, actors, and actor appelations (names).
See also: TEI references
Open Source Personal Tracking System Gets First Test
Nancy Gohring, InfoWorld
An open source wireless tracking system for following people around
buildings got its first public use last week at the Chaos Communication
Congress in Berlin. The creators of the OpenBeacon system sold 900 tags
at 10 Euros (US $13) each to attendees who volunteered to be tracked
during the four-day event. Some attendees bought multiple tags to
experiment with later. OpenBeacon uses chips from Nordic Semiconductor
ASA that transmit and receive over the 2.4GHz frequency, which is
available for unlicensed use in many countries. At the conference, the
chips communicated with nearby base stations which sent data back to a
central server. There were 23 base stations positioned around the
conference center. The developers of OpenBeacon worked with partners
to create a three dimensional model of the conference center and anyone
could use touch-screen monitors that displayed the location of attendees
on the model. Touching an attendee on the screen displayed a profile
that the person could voluntarily add. The OpenBeacon devices could be
distributed to 10,000 pilgrims traveling to Mecca, for example. Their
identities wouldn't be important but crowd control monitors could note
when many of the tagged pilgrims converge in one spot, implying that
potentially many other untagged people are also in the same area, and
then they could work to divert or otherwise alleviate the congestion,
Meriac said. The firmware, drivers and hardware design for the tracking
devices are released under GNU/GPL open source licenses. The base
station designs are not currently available as open source because they
were designed closely with a vendor. Meriac hopes that other contributors
will develop mesh protocols for the system so that the devices can
communicate with each other rather than only with a central base station.
See also: the conference web site
Long-term Fedora Linux Support Ending
Stephen Shankland, CNET News.com
Volunteers are calling it quits on a project called Fedora Legacy to
provide long-term support for Red Hat's hobbyist-oriented Fedora
version of Linux. Red Hat offers two versions of Linux, but only Red
Hat Enterprise Linux (RHEL) comes with long-term support. Fedora is a
faster-changing but free version that acts as a proving ground for new
technology. Red Hat offers only short-term, limited support for Fedora,
but volunteers on a project called Fedora Legacy tried to maintain the
free version longer. The idea was that the free version would be
something customers could rely on even after Red Hat's support ended.
It didn't work out. "The Fedora Legacy project is in the process of
shutting down," said project organizers Jesse Keating and David
Eisenstein in a Fedora Legacy mailing list posting Friday. The organizers
didn't provide a specific reason for the decision, but a lack of
contributions from outside programmers are part of the story... In the
days since Fedora Legacy got started, another free option for Red Hat
has cropped up: CentOS, an attempt to reproduce RHEL based on the real
project's underlying source code. More recently, Oracle has begun a
similar RHEL cloning effort. Also emerging on the scene in the years
since Fedora is Ubuntu, supported by start-up Canonical. Deliberately
taking a different approach than the Fedora-RHEL split, the free version
of Ubuntu is the same one for which Canonical sells support.
XML.org is an OASIS Information Channel
sponsored by BEA Systems, Inc., IBM Corporation, Innodata Isogen, SAP AG and Sun
Microsystems, Inc.
Use http://www.oasis-open.org/mlmanage
to unsubscribe or change an email address. See http://xml.org/xml/news_market.shtml
for the list archives. |
