Cover Pages: XML Daily Newslink: Thursday, 11 June 2009

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:
Sun Microsystems, Inc. http://www.sun.com

Headlines

Link Relations for Simple Version Navigation
Using the Twitter REST API
Navigating the SOA Open Standards Landscape Around Architecture
Validation Using Tries and Feature Sets
W3C Geolocation API Specification
First Look: Microsoft Silverlight 3 Challenges Adobe AIR
Uncoordinated Protocol Development Considered Harmful
Sieve Email Filtering: Sieves and Display Directives in XML

Link Relations for Simple Version Navigation
Al Brown and Julian F. Reschke, (eds) IETF Internet Draft

An initial draft version of Link Relations for Simple Version Navigation has been published by OASIS TC editors and TC members. Editor's note: "As part of the ongoing process of making the CMIS AtomPub protocol bindings a good citizen IETF-wise, we have been going through all the link relations it defines, and grouped them into CMIS-specific (these will use a CMIS-specific IRI and will not be registered), and general purpose. The second group consists of the hierarchy link relations we are already discussing (Nikunj's Internet-Draft "Hierarchy Relations for Atom"), and link relations for navigating version histories, which Al Brown and myself have been working on. This draft [for "Link Relations for Simple Version Navigation"] is just a start; we have a few open issues (marked as such), examples are missing, and I'd also like to discuss the relationship with JCR and WebDAV in an appendix, but didn't have time to do so yet. Nevertheless it would be nice to get early feedback about whether this makes sense, and whether something important is missing to make it useful in non-CMIS scenarios. Feedback is appreciated..."

From the Version -00 I-D: "This specification defines link relations that may be used on a resource that exists in a system that supports versioning to navigate among the different resources available, such as past versions... Several terms are defined, adopting definitions from Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning): 'Version-Controlled Resource, Checked-Out'; 'Checked-Out Resource'; 'Version Resource'; 'Version History Resource'; 'Predecessor, Successor, Ancestor, Descendant'; 'Root Version Resource'; 'Working Resource'.

The following link relations are defined: (1) all-versions: When included on a version controlled resource, this link points to a resource containing the version history for this resource. (2) latest-version: When included on a version controlled resource, this link points to a resource containing the latest (e.g., current) version. (3) working-copy: When included on a Checked-Out resource, this link points to a Working Resource. (4) predecessor-version: When included on a version resource, this link points to a resource containing the predecessor version in the version history...

Using the Twitter REST API
Brian M. Carey, IBM developerWorks

Twitter is undoubtedly one of the most recent and successful examples of social networking to appear on the World Wide Web. Twitter provides an API so Web developers can enable their users to access the various features that the Twitter site provides. In this article, learn the basics of using the Twitter REST API... Twitter is a fabulous entry in the Web 2.0 genre. Using Twitter, you can microblog your way to building an entire online network of individuals who share common interests with you. Using the Twitter REST API, you can automate just about everything you can do with Twitter manually. You can programatically access a specific user's timeline. You can reply to that user, either directly or indirectly. You can search a user's tweets for information specific to your own interests. You can filter tweets based on certain criteria and display those tweets on your own blog. The possibilities are endless...

Navigating the SOA Open Standards Landscape Around Architecture
Heather Kreger and Jeff Estefan (eds), Contribution to OASIS TC

This June 2009 White Paper (26 pages) was presented as a contribution to the OASIS SOA Reference Model Technical Committee, based upon joint authorship by The Open Group, OASIS, and OMG.

From the document 'Introduction': "This document is written to provide guidance to readers of various Service Oriented Architecture (SOA) standards and specifications written by the Organization for the Advancement of Structured Information Standards (OASIS), The Open Group, and the Object Management Group (OMG), on how these standards and specifications relate to each other. It is also intended to help clarify which specific works readers may wish to read as educational material to help better understand the SOA open standards landscape. This document does not detail all of the relevant SOA open standards work, but rather focuses on the distinguishing features of SOA reference models, reference architectures, maturity models, ontologies, modeling profiles, and governance specifications. As stated earlier, it is intended to serve as a guide to the reader to help differentiate the current and emerging specifications in that space, which is by no means a trivial undertaking... This document covers all audiences, although a particular document referenced may be aimed at a more narrow audience, such as the solution and enterprise architects who are the primary target practitioners seeking to leverage SOA open standards reference models, reference, architectures, ontologies, and SOA modeling profiles as part of their work...

The specifications and standards described in this White Paper can be used together in many complementary ways. An excellent example is incorporating the use modeling techniques into an SOA project by using SoaML in concert with an SOA reference architecture. In addition, the SOA reference models, ontology, and reference architectures described in this document can be used as input to requests for proposals (RFPs) that extend SoaML with additional modeling capabilities..."

Note: Service Oriented Architecture Modeling Language (SoaML) — Specification for the UML Profile and Metamodel for Services (UPMS) [OMG document: ad/2008-11-01] "describes a UML profile and metamodel for the design of services within a service-oriented architecture. The SoaML profile supports the range of modeling requirements for service-oriented architectures, including the specification of systems of services, the specification of individual service interfaces, and the specification of service implementations. This is done in such a way as to support the automatic generation of derived artifacts following an MDA based approach. Use of the profile is illustrated with a complete example. The SoaML metamodel is based on the UML2 metamodel L3 and provides minimal extensions to UML, only where absolutely necessary to accomplish the goals and requirements of service modeling. The specification takes advantage of the package merge feature of UML2 to merge the extensions into UML. The profile provides a UML specific version of the metamodel that can be incorporated into standard UML modeling tools..."

Validation Using Tries and Feature Sets
Rick Jelliffe, O'Reilly Technical

A critical decision in a designing a schema language is to decide whether validation is an operation that should be performable in a single (or some bounded number) of passes over the document (such as an unambiguous grammar), by a number of parallel passes or backtracking (such as ambiguous grammars), or whether it can utilize random access (such as Schematron's XPaths.)... However, there is another design or implementation option for validation, which is to generate a trie for the document, then to validate that trie. Because our schema languages attempt to validate more than a trie can represent, in fact we also must extract a feature set from our schemas: this is true whether the schema is a grammar-based schema or a Schematron-style schema. This gives us weak validation (a note I wrote on this a decade ago, and here I am still banging on about it), but it also may allow performance or implementation characteristics that may be useful in some situations, in particular for efficient single-pass streaming validation of very large documents. Knuth's treatment of tries is very clear... Regular readers will see this as related to other material I have talked about: progressive validation, feasible validation, partial ordering (Hook), usage schema, path validation language Using weaker schemas is of course one of the great reliefs when implementing schema converters, such as the XSD to Schematron converter...

See also: XML Schema Languages

W3C Geolocation API Specification
Andrei Popescu (ed), W3C Geolocation Working Group Draft

Members of the W3C Geolocation Working Group, part of the Ubiquitous Web Applications Activity, are actively working through issues directed at production of the "Geolocation API Specification", including exposing civic addresses in the API, privacy, etc. This WG was chartered to develop one or more Recommendation Track documents that define interfaces for making this information accessible within the User-Agent. The interface should be usable regardless of the source of location information, and should be consistent across location technologies. Scope: "The number of Web enabled devices that are location-aware has increased markedly as of late. These devices are very common and include mobile phones with cell triangulation or Global Positioning System (GPS) capabilities, laptops with Wi-Fi triangulation capabilities and GPS receivers. The Geolocation WG is created in response to requests from the community for W3C to develop a standardized, secure and privacy- sensitive interface so that Web applications may gain access to location information..."

The draft specification "defines an API that provides scripted access to geographical location information associated with the hosting device. The API defines a high-level interface to location information associated only with the device hosting the implementation, such as latitude and longitude. The API itself is agnostic of the underlying location information sources. Common sources of location information include Global Positioning System (GPS) and location inferred from network signals such as IP address, RFID, WiFi and Bluetooth MAC addresses, and GSM/CDMA cell IDs, as well as user input. No guarantee is given that the API returns the device's actual location. The API is designed to enable both "one-shot" position requests and repeated position updates, as well as the ability to explicitly query the cached positions. Location information is represented by latitude and longitude coordinates. The Geolocation API in this specification builds upon earlier work in the industry..."

First Look: Microsoft Silverlight 3 Challenges Adobe AIR
Martin Heller, InfoWorld

"Microsoft Silverlight 3 is catching up to the capabilities of Adobe Flash, Flex, and AIR in all the areas where Silverlight was behind. Silverlight 3 applications can run in or out of the browser, online or offline, with much improved audio, video, and 3-D graphics... For designers, the Expression Blend 3 Preview already imports Adobe Photoshop and Illustrator files, another lack in Blend 2, and will add "SketchFlow" prototyping and interactive behaviors in a future release... One problem area that Flash and Silverlight have had in common is SEO (search engine optimization). A search engine such as Google can only see the text on a Web page; RIA applications historically have not displayed usable text or allowed external links to states "deep" inside the animation, concentrating instead on their forte—flashy graphics. Recently there's been some improvement in SEO for Flash and Flex, using external JavaScript objects such as SWFObject (for dynamic loading) and SWFAddress (for deep linking), at least for those who to take the trouble to revamp their Flash sites; Silverlight 3 addresses both SEO and deep linking internally..."

See also: Silverlight 3

Uncoordinated Protocol Development Considered Harmful
Stewart Bryan and Monique Morrow, Internet Architecture Board Draft

On behalf of the Internet Architecture Board (IAB), Stewart Bryan and Monique Morrow have released an Internet Draft for "Uncoordinated Protocol Development Considered Harmful." This document "identifies various types of damage that may occur without formal coordination and joint development on protocols of mutual interest between standards development organizations. The IAB has selected T-MPLS as recent case study to describe hazard to both the MPLS and Internet architecture as a result of uncoordinated adaptation of a protocol. This experience has resulted in a considerable improvement in the relationship between the two organisations. In particular, this was achieved via the establishment of the 'Joint working team on MPLS-TP' which was the first ever joint ITU/IETF group. In addition, the leadership of the two organisations have agreed to improve inter-organizational working practices so as to avoid conflict in future between ITU-T Recommendations and IETF RFCs."

Note: "The IAB is chartered both as a committee of the Internet Engineering Task Force (IETF) and as an advisory body of the Internet Society (ISOC). Its responsibilities include architectural oversight of IETF activities, Internet Standards Process oversight and appeal, and the appointment of the RFC Editor. The IAB is also responsible for the management of the IETF protocol parameter registries."

Sieve Email Filtering: Sieves and Display Directives in XML
Ned Freed and Srinivas Saisatish Vedam (eds), IETF Internet Draft

Members of the IETF Sieve Mail Filtering Language (SIEVE) have released an updated Internet Draft specification for Sieve Email Filtering: Sieves and Display Directives in XML. This document "describes a way to represent Sieve email filtering language scripts in XML. Representing sieves in XML is intended not as an alternate storage format for Sieve but rather as a means to facilitate manipulation of scripts using XML tools. The XML representation also defines additional elements that have no counterparts in the regular Sieve language. These elements are intended for use by graphical user interfaces and provide facilities for labeling or grouping sections of a script so they can be displayed more conveniently. These elements are represented as specially structured comments in regular Sieve format."

This version makes several substantial changes, including Added an IANA registration of a URN for the Sieve namespace; Updated XML Schema to allow largely unrestricted use of material in other namespaces; Add compact Relax NG schema; Updated example stylesheet to handle material in other namespaces; Corrected stylesheet handling of 'comment' elements; Added a section defining the structured comment convention; Added text to clarify that the examples in the various appendices are in fact code components and may therefore be reused; Added a section on validation requirements; Clarified various editor requirements and trust issues, restricted the use of "*/" in non-Sieve XML content; etc.

As defined in RFC 5228, Sieve: An Email Filtering Language describes a language for "filtering email messages at time of final delivery. It is designed to be implementable on either a mail client or mail server. It is meant to be extensible, simple, and independent of access protocol, mail architecture, and operating system. It is suitable for running on a mail server where users may not be allowed to execute arbitrary programs, such as on black box Internet Message Access Protocol (IMAP) servers, as the base language has no variables, loops, or ability to shell out to external programs..."


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

Headlines

Sponsors