Robin Cover

XML Daily Newslink. Friday, 22 February 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
SAP AG http://www.sap.com
====================================================

HEADLINES:

* HTTP-based IETF Namespace URIs at IANA
* OpenGIS Web Processing Service (WPS) Interface Standard Version 1.0
* Addressing Fragments in REST
* Microsoft Readies Silverlight 2 Beta
* Last Call Working Draft for RDFa in XHTML: Syntax and Processing
* vCard Extensions to WebDAV (CardDAV)

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

HTTP-based IETF Namespace URIs at IANA
Martin Duerst and Tim Bray (eds), IETF Internet Draft

The draft I-D "HTTP-based IETF Namespace URIs at IANA" creates a registry
and defines a procedure to allow IETF specifications to register XML
Namespace Names with IANA which are HTTP URIs and thus potentially useful
for looking up information about the namespace. Many IETF specifications
use Extensible Markup Language (XML) 1.0 (Fourth Edition) with Namespaces
in XML 1.0 (Second Edition). XML Namespace Names are URIs, and there are
many options for constructing them. One of the options is the use of HTTP
URIs -- those whose scheme is 'http:'. IETF RFC 3688 (The IETF XML
Registry) created an IANA registry for XML namespaces based on URNs,
which take on the form 'urn:ietf:params:xml:ns:foo'. RFC 3470 observes
that in the case of namespaces in the IETF standards-track documents,
it would be useful if there were some permanent part of the IETF's own
web space that could be used to mint HTTP URIs. However, it seems to
be more appropriate and in line with IETF practice to delegate such a
registry function to IANA... IANA maintains a registry page listing the
registered XML namespaces which use HTTP URIs. For each registered
namespace, the registry page includes a human-readable name for the
namespace, a link to the namespace document, and the actual namespace
URI. Namespaces created by IANA upon registration have the following form.
There is a common prefix, "http://www.iana.org/xmlns/" [...] followed
by a unique identifier. The unique identifier should be a relatively
short string of US-ASCII letters, digits, and hyphens, where a digit
cannot appear in first position and a hyphen cannot appear in first or
last position or in successive positions. In addition, the unique
identifier can end in a single '/' or '#'. XML namespaces are
case-sensitive, but all registrations are required to mutually differ
even under case-insensitive comparison. For uniformity, only lower
letters should be used. A unique identifier is proposed by the requester,
but IANA may change it as they see fit, in consultation with the
responsible Expert Reviewer. For each namespace registered, there must
be a namespace document in either HTML or XHTML which may be retrieved
using the HTTP URI which is the registered namespace name. It contains
the template information with appropriate markup. The request for creation
and registration of a HTTP XML Namespace URI is made by including a
completed registration template in the IANA Considerations section of
an Internet-Draft.

http://xml.coverpages.org/namespaces.html#IANA-NamespaceURIs

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

OpenGIS Web Processing Service (WPS) Interface Standard Version 1.0
Staff, OGC Announcement

OGC announced that members of the Open Geospatial Consortium have
approved version 1.0 of the OpenGIS Web Processing Service (WPS)
Interface Standard. The WPS standard defines an interface that
facilitates the publishing of geospatial processes and makes it easier
to write software clients that can discover and bind to those processes.
Processes include any algorithm, calculation or model that operates on
spatially referenced raster or vector data. Publishing means making
available machine-readable binding information as well as human-readable
metadata that allows service discovery and use. A WPS can be used to
define calculations as simple as subtracting one set of spatially
referenced data from another (e.g., determining the difference in
influenza cases between two different seasons), or as complicated as a
hydrological model. The data required by the WPS can be delivered across
a network or it can be made available at the server. This interface
specification provides mechanisms to identify the spatially referenced
data required by the calculation, initiate the calculation, and manage
the output from the calculation so that the client can access it. The
OGC's WPS standard will play an important role in automating workflows
that involve geospatial data and geoprocessing services. The specification
identifies a generic mechanism to describe the data inputs required and
produced by a process. This data can be delivered across the network, or
available at the server. This data can include image data formats such
as GeoTIFF, or data exchange standards such as Geography Markup Language
(GML). Data inputs can be legitimate calls to OGC web services. For
example, a data input for an intersection operation could be a polygon
delivered in response to a WFS request, in which case the WPS data input
would be the WFS query string.

http://xml.coverpages.org/OpenGIS-WPS-V10.html
See also Geography Markup Language (GML): http://xml.coverpages.org/geographyML.html

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

Addressing Fragments in REST
Simon St. Laurent, O'Reilly Technical

REST offers a great way to build simple applications that Create, Read,
Update, and Delete resources. But what if you want to get at part of a
resource? A database row is a simple thing, even if it enables immense
complexity. It contains named fields - no more than one to a given name,
usually conforming to a rather predictable schema. There's nothing
floating between the fields, and every row contains the same set of
fields. (They may be empty, of course, but they're clearly defined. An
XML document - or even an XML document fragment - is potentially incredibly
complicated. While many XML documents are regular and relatively simple,
the ones that aren't simply holding data as it moves between databases
are often very complicated. XML elements are kind of like fields, sure,
but [not quite...] Nonetheless, it seems like the basic operations most
people would like to perform on these documents (and other loosely-structured
resources) are the same operations people want to perform on database
records: Create, Read, Update, Delete. CRUD is everywhere, and CRUD is
good. Typically, though, an XML document is treated as a single resource.
A book might assemble itself using entities or XIncludes that pull in
chapters, of course, and those chapters could be individually addressed
as resources, but that has limits. Though it's possible, I don't think
anyone wants to write paragraphs in which each sentence is included from
a separate file using one of those mechanisms. As soon as you hit mixed
content, the entity approach breaks down anyway. (Other formats, like JSON,
don't have entities but share a few of the same problems.) So how can
developers build RESTful applications that address parts of documents?
One approach that's getting a lot of discussion in the last few days is
to add a new verb, PATCH, to HTTP... It seems to me that the problem is
not that developers want to do something that can't be expressed with a
RESTful verb - in this case, probably UPDATE. The problem is that developers
can't address the resource on which they want to work with sufficient
granularity given their current set of tools and agreements. Though I've
inveighed against the many many sins of XPointer for years, that
incredibly broken process was at least working to solve the problem of
addressing XML documents at a very fine granularity, extending the tool
most commonly used on the client side for this: fragment identifiers...

http://www.oreillynet.com/xml/blog/2008/02/addressing_fragments_in_rest_1.html

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

Microsoft Readies Silverlight 2 Beta
Paul Krill, InfoWorld

Microsoft's Scott Guthrie, general manager in the Microsoft Developer
Division, has provided a list of features planned for Silverlight 2 and
the beta, planned for release during the first quarter of 2008.
Silverlight 2 will be a major update of Silverlight that focuses on
enabling Rich Internet Application (RIA) development. Silverlight 2
includes a cross-platform, cross-browser version of the .NET Framework,
and enables a rich .NET development platform that runs in the browser.
Once Silverlight 2 is installed, you can browse the Web and automatically
run rich Silverlight applications within your browser of choice; thus
includes such browsers as Internet Explorer, Firefox, Safari, and others.
For networking, Silverlight 2 backs REST (Representational State Transfer),
WS-*, and SOAP as well RSS, POX, and HTTP services. Cross-domain network
access in Silverlight 2 enables Silverlight clients to directly access
resources and data from resources on the Web. Built-in sockets networking
also is included in the beta release. Silverlight 2 features a rich .Net
base class library of functionality, such as collections, generics
threading, globalization, XML, and local storage. Rich APIs in the
product enable HTML DOM/JavaScript integration with .Net code Also featured
is Microsoft's LINQ (Language Integrated Query) technology, which provides
native query syntax for C# and Visual Basic, and LINQ to XML library
support. This enables easy transformation and querying of data; local
data caching and storage support are highlighted as well in Silverlight 2.
Developers can write Silverlight applications using a .Net language, such
as Visual Basic, C#, JavaScript, IronPython, or IronRuby. Microsoft plans
to ship support for developer/designer workflow and integration for
Silverlight in its Visual Studio 2008 and Expression Studio tools.

http://www.infoworld.com/article/08/02/22/ms-silverlight_1.html
See also First Look at Silverlight 2: http://weblogs.asp.net/scottgu/archive/2008/02/22/first-look-at-silverlight-2.aspx

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

Last Call Working Draft for RDFa in XHTML: Syntax and Processing
Ben Adida, Mark Birbeck (et al., eds); W3C Technical Report

Members of W3C's Semantic Web Deployment Working Group and the XHTML 2
Working Group have published a Last Call Working Draft for the
specification "RDFa in XHTML: Syntax and Processing A collection of
attributes and processing rules for extending XHTML to support RDF."
RDFa is a specification for attributes to be used with languages such
as HTML and XHTML to express structured data. The rendered, hypertext
data of XHTML is reused by the RDFa markup, so that publishers don't
need to repeat significant data in the document content. This document
only specifies the use of the RDFa attributes with XHTML. The underlying
abstract representation is RDF, which lets publishers build their own
vocabulary, extend others, and evolve their vocabulary with maximal
interoperability over time. The expressed structure is closely tied to
the data, so that rendered data can be copied and pasted along with its
relevant structure. The rules for interpreting the data are generic, so
that there is no need for different rules for different formats; this
allows authors and publishers of data to define their own formats without
having to update software, register formats via a central authority, or
worry that two formats may interfere with each other. RDFa shares some
use cases with microformats. Whereas microformats specify both a syntax
for embedding structured data into HTML documents and a vocabulary of
specific terms for each microformat, RDFa specifies only a syntax and
relies on independent specification of terms (often called vocabularies
or taxonomies) by others. RDFa allows terms from multiple independently
developed vocabularies to be freely intermixed and is designed such that
the language can be parsed without knowledge of the specific term
vocabulary being used. Motivation: RDF/XML (Syntax) provides sufficient
flexibility to represent all of the abstract concepts in RDF. However,
it presents a number of challenges; first it is difficult or impossible
to validate documents that contain RDF/XML using XML Schemas or DTDs,
which therefore makes it difficult to import RDF/XML into other markup
languages. Whilst newer schema languages such as RELAX NG do provide a
way to validate documents that contain arbitrary RDF/XML, it will be a
while before they gain wide support. Second, even if one could add RDF/XML
directly into an XML dialect like XHTML, there would be significant data
duplication between the rendered data and the RDF/XML structured data.
It would be far better to add RDF to a document without repeating the
document's existing data. One motivation for RDFa has been to devise a
means by which documents can be augmented with metadata in a general
rather than hard-wired manner. This has been achieved by creating a
fixed set of attributes and parsing rules, but allowing those attributes
to contain properties from any of a number of the growing range of
available RDF vocabularies. The values of those properties are in most
cases the information that is already in an author's XHTML document.

http://www.w3.org/TR/2008/WD-rdfa-syntax-20080221/
See also the W3C Semantic Web Activity: http://www.w3.org/2001/sw/

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

vCard Extensions to WebDAV (CardDAV)
Cyrus Daboo (ed), IETF Internet Draft

Members of the IETF vCard and CardDAV (VCARDDAV) Working Group have
released an updated version of the specification "vCard Extensions to
WebDAV (CardDAV)." This IETF WG was chartered to produce: (1) A revision
of the vCard specification (RFC 2426) at proposed standard status; this
revision will include other vCard standardized extensions (RFC 2739,
4770) and extensions assisting synchronization technologies -- for
example, a per-entry UUID or per-attribute sequence number; other
extensions shall be considered either in the base specification or in
additional documents; (2) An address book access protocol leveraging
the vCard data format, for which the 'draft-daboo-carddav' I-D is the
starting point; (3) An XML schema which is semantically identical to
vCard in all ways and can be mechanically translated to and from vCard
format without loss of data. While vCard has deployed successfully and
will remain the preferred interchange format, a standard XML schema
which preserves vCard semantics might make vCard data more accessible
to XML-centric technologies such as AJAX and XSLT. Such a standard format
would be preferable to multiple proprietary XML schemas, particularly if
vCard semantics were lost by some of them and a lossy gateway problem
resulted. The draft "vCard Extensions to WebDAV (CardDAV)" defines
extensions to the Web Distributed Authoring and Versioning (WebDAV)
protocol to specify a standard way of accessing, managing, and sharing
contact information based on the vCard format. Address books containing
contact information are a key component of personal information management
tools, such as email, calendaring and scheduling, and instant messaging
clients. To date several protocols have been used for remote access to
contact data, including Lightweight Directory Access Protocol (LDAP),
Internet Message Support Protocol (IMSP) and Application Configuration
Access Protocol (ACAP - RFC 2244), together with SyncML used for
synchronization of such data. Each has key disadvantages... The proposed
CardDAV address book is modeled as a WebDAV collection with a well
defined structure; each of these address book collections contain a
number of resources representing address objects as their direct child
resources. Each resource representing an address object is called an
"address object resource". Each address object resource and each address
book collection can be individually locked and have individual WebDAV
properties. Definitions of XML elements in this document use XML element
type declarations (as found in XML Document Type Declarations), described
in Section 3.2 of the XML 1.0 Recommendation.

http://xml.coverpages.org/draft-daboo-carddav-04.txt
See also the IETF vCard and CardDAV (VCARDDAV) Working Group: http://www.ietf.org/html.charters/vcarddav-charter.html

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

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. Friday, 22 February 2008