Cover Pages: XML Daily Newslink: Tuesday, 27 July 2010

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:
Microsoft Corporation http://www.microsoft.com

Headlines

OGC Identifiers: The Case for http Scheme URIs
W3C Releases First Public Working Draft of WOFF File Format 1.0
CMIS Browser Binding Proposal Version 0.1
SAML 2.0 Bearer Assertion Profile for OAuth 2.0
Query XML Documents Outside an XML Database
Open Geospatial Invites Comment on the MovingObjectSnapshot Standard
Radiant Logic Showcases ID-Connect at Burton Catalyst Conference
Status Quo: The Silent Killer

OGC Identifiers: The Case for http Scheme URIs
Simon Cox (ed), Open Geospatial Consortium Approved White Paper

In June 2010 at the NOAA Silver Spring OGC Meetings, members of the Open Geospatial Consortium (OGC) approved release of the OpenGIS White Paper OGC Identifiers: The Case for http URIs as OGC 10-124r1. According to the OGC policy preceding this action, "either URNs or http scheme URIs could be used in OGC standards. However, the use of http URIs: (a) resolves some deployment challenges, and (b) provides an opportunity for easier engagement with broader communities. So OGC should now consider taking the next step, and mandate the use of http URIs for persistent identifiers in OGC specifications. The whitepaper discusses a number of issues around this proposal.

The corresponding 'http URI Policy' approved by OGC is now represented as official OGC policy, to be included in the OGC Policies related to OGC standards [OGC 06-135rN]: 'OGC TC directs the OGC-NA that all new OGC identifiers issued for persistent public OGC resources shall be http URIs, instead of URNs. New standards and new major versions of existing standards shall use http URIs for persistent public OGC resources to replace OGC URN identifiers defined in previous standards and versions, unless OGC-NA approves an exception. Operational Implications: OGC should carefully manage (maintain for the long term) the 'http://www.opengis.net' Internet domain and identifiers in this domain.'

Excerpts from the White Paper: "At the time that OGC started using URNs, it appeared to be a good option for persistent identification, avoiding some undesirable effects and expectations around URLs. In particular, URN NID registrations (governed by IETF through IANA) are forever, while http domain registration is periodic, and http server maintenance is a skilled job. There was also a principle at stake: identification and location are different functions. However, deployment and maintenance of a resolver service for URNs has been a challenge for OGC, particularly as there is no standard for a URN resolution service, and no best practice or precedent to fall back on...

Meanwhile, however, the use and interpretation of URIs on the web has evolved significantly... an 'http URI' may serve as a persistent identifier, and when used in this sense, the URI is interpreted trivially as a text-string where the presence of '/' and ':' characters is unimportant in that context. An http scheme URI has the highly desirable characteristic that it is also a URL and thus provides the opportunity for automatic resolution, following standard internet conventions; use of the DNS system and http protocol mean that no special resolver service is required. The latter overcomes a legitimate criticism of all non-http URI schemes. For OGC this creates a significant opportunity. Generic tools (browsers, reasoners) have built-in support for binding to http URIs, without any customization, so the adoption of http URIs would allow documents referring to resources with OGC identifiers to be used more effectively in the generic web context. There is no requirement for the consumer to use a specific resolver service, so no requirement that everyone who encounters an OGC document to know where the OGC resolver is, what the invocation method is, or to cache definitions corresponding to OGC names in advance of encountering them..." [Comparative note: in W3C, HTTP scheme NS URIs are prescribed; in OASIS, HTTP scheme NS URIs are recommended and preferred, but other URI schemes are allowed.]

W3C Releases First Public Working Draft of WOFF File Format 1.0
Jonathan Kew, Tal Leming, Erik van Blokland (eds), W3C Technical Report

Members of the W3C WebFonts Working Group have published a First Public Working Draft for the WOFF File Format 1.0 specification. The document specifies a simple compressed file format for fonts, designed primarily for use on the web. The WOFF format is a container for the table-based sfnt structure used in TrueType, OpenType and Open Font Format fonts, which are collectively referred to as sfnt-based fonts. A WOFF file is simply a repackaged version of a sfnt-based font with optional compression of the font data tables. The WOFF file format also allows font metadata and private-use data to be included separately from the font data. WOFF encoding tools convert an existing sfnt-based font into a WOFF formatted file, and user agents restore the original sfnt-based font data for use with a web page.

In general, the structure and contents of decoded font data exactly match those of the original font file. Tools producing WOFF files may provide other font editing features such as glyph subsetting, validation or font feature additions but these are considered outside the scope of this format. Independent of these features, both tools and user agents must assure that the validity of the underlying font data is preserved.

The primary purpose of the WOFF format is to package fonts linked to web pages by means of CSS '@font-face' rules. When using such fonts, user agents MUST implement a 'same-origin restriction' on the downloading of WOFF files using the same-origin matching algorithm described in the HTML5 specification. Note that the origin of the stylesheet containing '@font-face' declarations is not used when deciding whether a WOFF file is same-origin or not, only the origin of containing document is used. User agents MUST also implement the ability to relax this restriction using Cross-Origin Resource Sharing. Thus, sites can explicitly allow cross-site downloading of WOFF files using the Access-Control-Allow-Origin HTTP header.

User agents supporting the WOFF file format for downloadable fonts MUST respect the requirements of the CSS Fonts specification. In particular, such downloaded fonts are only available to the documents that reference them; they MUST NOT be made available to other applications or documents on the user's system..."

CMIS Browser Binding Proposal Version 0.1
Gregory Melahn, Draft Contribution to CMIS Browser Binding Subcommittee

An early draft CMIS Browser Binding Proposal Version 0.1 has been posted to the OASIS CMIS Browser Binding Subcommittee document repository. The editor's initial goal is to get agreement on the specification outline, and then fill out more details; in the next iteration the SC members would add more details in particular about update using post and multipart post, as well as query. This document is an initial draft deliverable produced within the newly formed CMIS Browser Binding Subcommittee.

Overview: "The CMIS Browser Binding is intended to make it simpler for browser-based applications to find, create, update and delete content stored in CMIS repositories. Also this binding is optimized for use in browser applications, it can also be useful as a simpler HTTP based binding in other application models.

Protocol: HTTP shall be used as the protocol for service requests. HTTP GET shall be used for reading content and HTTP POST shall be used for creating, updating and deleting content. Data Representation: Browser applications are typically written in JavaScript and a popular lightweight data representation format amongst JavaScript developers is JavaScript Object Notation (JSON) as described in RFC 4627. So in this binding JSON shall be used to represent CMIS repositories, folders, documents, relationships and policies. Mapping Schema Elements to JSON: JSON only defines a few types, including Object, String, Number, Boolean, Null, and Arrays. Since not all the types used in the CMIS schema have direct JSON equivalents, some explanation of mapping is necessary.

[As to] Referencing Resources by Path and by Id: Resources can be referenced using either the full path or by Id. When path is used, URI used to address the resource shall be relative to the rootFolderUri returned from the getRepositoryInfo service. In the case of Id, the request parameter id shall be used. For example, referencing an object by path: 'GET /cmis/repository/123/myFolder/myDocument' and referencing an object by id: 'GET /cmis/repository/123?id=0192018282'... [As to Paging] Since the number of objects returned from the navigation services can be huge, a mechanism for paging is provided. The optional input parameters defined on the navigation services, maxItems and skipCount, shall be represented as HTTP request parameters of the same name. A JSON object with the key cmis:pageinfo shall be present if the request parameter maxItems is present. This object shall have the following JSON key/value pairs: 'boolean' hasMoreItems and 'number' numItems..."

SAML 2.0 Bearer Assertion Profile for OAuth 2.0
Brian Campbell and Chuck Mortimore (eds), IETF Internet Draft

Members of the IETF Open Authentication Protocol (OAuth) Working Group have published an initial level -00 Internet Draft for the specification SAML 2.0 Bearer Assertion Profile for OAuth 2.0. The IETF OAuth Working Group was chartered to advance the OAuth standard(s) by improving interoperability, extensibility, clarity of semantics, etc. OAuth "allows a user to grant a third-party Web site or application access to their resources, without necessarily revealing their credentials, or even their identity. For example, a photo-sharing site that supports OAuth would allow its users to use a third-party printing Web site to access their private pictures, without gaining full control of the user account..."

The new 'SAML 2.0 Bearer Assertion Profile' specification defines the use of a SAML 2.0 bearer assertion as means for requesting an OAuth 2.0 access token. The Security Assertion Markup Language (SAML) 2.0 is an XML-based framework that provides a means for a subject to be identified across security domains. The SAML specification, while primarily targeted at providing cross domain web browser single sign-on, was also designed to be modular and extensible to facilitate use in other contexts. The Assertion, an XML security token, is a fundamental construct of SAML that is most often adopted for use in other protocols and specifications. An assertion is generally issued by an identity provider and consumed by a service provider who relies on its content to identify the subject for security related purposes.

OAuth Version 2.0 provides a method for making authenticated HTTP requests to a resource using an access token. Tokens are issued to third-party clients by an authorization server with the (sometimes implicit) approval of the resource owner. OAuth defines multiple profiles for obtaining access tokens to support a wide range of client types and user experiences. One such method is the use of an assertion which supports the case when a client wishes to exchange an existing security token for an access token. However the Oauth 2.0 leaves the specific format and validation of the assertion out of scope... The new I-D accordingly profiles the specific use of a SAML 2.0 bearer assertion in requesting an access token using the assertion 'grant_type' from OAuth 2.0..."

Editor's initial note to the IETF OAuth discussion list: "Attached is a draft that aims to tightly define the particular format of a SAML 2.0 bearer assertion in requesting an access token using the assertion 'grant_type'. I've been working with Chuck at Salesforce.com on this and the primary goal is to have some documentation or specification that is sufficient to facilitate interoperability between independently developed implementations or products. This, of course, wouldn't preclude using SAML in other ways; it would only provide one concrete definition to implement against..."

Query XML Documents Outside an XML Database
Adriaan de Jonge, IBM developerWorks

"The majority of XML data is not typically stored in XML databases. Although XQuery is well known for its database querying capabilities, you do not need a database for XQuery to be powerful. You can also use XQuery to investigate and analyze XML documents residing in various non-XML storage media.

For example, Java developers use Maven Project Object Model (POM) files to build their projects and manage dependencies. Maven can best be described as a Java build tool that specializes in dependency management; Maven is typically the only program using the information contained in a Maven POM file. But because POM files are XML, you can just as easily read them using XQuery and do your own analysis. You can ask questions such as, 'How many of my projects are still using the old version of Log4J?'...

XQuery has been an official W3C recommendation since 2007, and it's widely supported. Traditional databases like IBM DB2, Oracle, and Microsoft SQL Server all support XQuery for XML processing. Native XML databases like eXist and MarkLogic Server are the natural playing ground for XQuery. A large number of small commercial, open source, and academic XQuery implementations are also available on the Internet, and some are even bundled with a native XML database. Others are stand-alone XQuery processors not tied to a database.

A well-known stand-alone XQuery processor is Saxon Home Edition (Saxon-HE), the open source edition of Saxonica. This processor supports XSLT version 2.0 and XPath version 2.0 and is optimized for performance. This article demonstrates the use of XQuery outside database environments using Saxon..."

Open Geospatial Invites Comment on the MovingObjectSnapshot Standard
Staff, Open Geospatial Consortium (OGC) Announcement

OGC is now seeking public comment on a Geography Markup Language (GML) XML encoding for describing the characteristics of a moving object, such as a GPS enabled car. This candidate standard provides a way of describing in simple terms the motion of an object, such as a car driving through city streets or a person walking in a park. The public comment period closes on August 23, 2010.

'OGC MovingObjectSnapshot: An Application Schema of the OGC Geography Markup Language' (edited by George Percivall and David Burggraf) in candidate standard form fills a need for 'lightweight' packets of tracking information, such as direction and velocity that can be communicated between diverse platforms and applications supporting mobile location-aware devices. The GML encoding used in this candidate standard is compatible with a wide range of other standard encodings used in other communities, such as emergency services.

Typical use cases for the moving object defined in this specification are a car driving through city streets or a human walking in a park. The velocity defined in this specification is applicable to the instantaneous, translational motion of an object moving relative to a two-dimensional plane. The object may be a single point or the centre of mass of a rigid body, such as a car. The coordinate system is a Local Tangent Plane that includes North as a coordinate axis...

The document defines a GML application schema to encode a snapshot of a moving object including its location, translational velocity and acceleration. The velocity is an instantaneous vector composed of a scalar speed and a heading relative to North... Data using this specification must produce an XML document compliant with the XML 'MovingObjectSnapshotType' as defined in the schema..."

Radiant Logic Showcases ID-Connect at Burton Catalyst Conference
Staff, Radiant Logic Announcement

"Radiant Logic, leader in virtual directory technology, has announced ID-Connect and Context Browser, two web-based client applications for RadiantOne VDS Context Edition version 5.3. Due out in August, Radiant Logic demos both applications at the Burton Group Catalyst Conference in San Diego, July 26-30, 2010.

ID-Connect is a social networking-based interface that allows enterprises to tap into the increasingly important world of social networking. Context Browser is an innovative contextual search tool that links structured data scattered across databases and applications and organizes it into meaningful contextual information.

Based on Silverlight, ID-Connect is a social networking-based interface integrated with Microsoft SharePoint as a Web Part, or as JSP pages for any J2EE web server, such as Apache Tomcat. ID-Connect provides a unified view of identity and profile attributes based on virtualization, pulled from heterogeneous and distributed data sources both inside and outside the enterprise firewall. Using the RadiantOne Identity and Context virtualization server, ID-Connect builds a complete view of identity and profiles out of different data silos without modifying the existing identity infrastructure, by aggregating information from directories, LDAP and databases, as well as cloud-based applications such as SalesForce or Google Apps...

With ID-Connect, identity and profiles are fully secured and access is granted based on access rights/dynamic groups and user-defined policies. Identity profile attribute data can be managed in one place and, where allowed, updated attributes can be changed within the original sources. In addition, individualized attributes can be created and secured in a local LDAP directory, which acts as a personal data locker, so updates can be written back to the local LDAP store, instead of having to extend other data source schemas to support these additional attributes..."

See also: the RadiantOne Platform

Status Quo: The Silent Killer
Tom Costello, IT Professional

"There's an old saying in consulting: 'Status quo is our greatest competitor.' This has always been true for consulting, but it's now becoming the mantra of internal IT organizations, as well. No change should be good news for an IT team, giving the team a breather to prepare for the coming growth, right? Wrong...

As executives optimize their bottom line by weeding out every last dollar of company waste, IT has become their top target for finding and proving value. IT executives' responses have ranged from taking practical steps — such as optimizing internal IT operations by reducing labor costs, reviewing contracts, and so on—to tackling bigger challenges, such as project management and portfolio control. However, non-IT executives have gone too far and are now asking IT to justify (not simply explain) the business value of every initiative that touches IT.

One of the obvious trends over the past several decades has been implementing large-scale packages (such as enterprise resource planning or customer relationship management). Although you could argue that implementing these packages lets a firm on the lower end of the bell curve quickly leap upward (to the right), many believe this homogenizes the industry vertical by removing nearly all differentiation. Depending on what factors differentiate you from your competitors, and whether those factors are even components of your package implementation, this argument can swing either way...

The shame of the current market is that many firms are trying to live in the 'status quo' model and yet are expecting to find better numbers through IT regardless of where they fall on the technology impact curve. Furthermore, executive teams are challenging CIOs to produce cost/benefit information and business justification that simply isn't owned by IT — in fact, such justifications might not even exist..."


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

Headlines

Sponsors