Cover Pages: XML Daily Newslink: Friday, 22 February 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:
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 Dürst 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.

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.

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

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.

See also: First Look at Silverlight 2

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.

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


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

Headlines

Sponsors