OASIS Opens Public Review for Test Assertions v1.0 Specifications

Stephen Green and Dmitry Kostovarov (eds), OASIS Committee Drafts

Members of the OASIS Test Assertions Guidelines (TAG) Technical Committee
have released three approved Committee Draft specifications for public
review through May 09, 2010. This OASIS TC was chartered in April 2007
in to "facilitate the creation and usage of test assertions by any group
involved in designing a specification or standard of which software
implementations are expected to be developed, with a primary focus on
OASIS technical committees. The first step in achieving this is to
establish a common and reusable model, metadata, methodology and
representation for TAs (test assertions).

"Test Assertions Part 1 - Test Assertions Model Version 1.0" specifies
"mandatory and optional components of a test assertion model. A test
assertion is a testable or measurable expression for evaluating the
adherence of part of an implementation to a normative statement in a
specification. It describes the expected output or behavior for the
test assertion target within specific operation conditions, in a way
that can be measured or tested. A Test Assertion should not be confused
with a Conformance Clause, nor with a Test Case... Test assertions
may help provide a tighter specification: Any ambiguities,
contradictions and statements which require excessive resources for
testing can be noted as they become apparent during test assertion
creation. If there is still an opportunity to correct or improve the
specification, these notes can be the basis of comments to the
specification authors. If not developed by the specification authors,
test assertions should be reviewed and approved by them which will
improve both the quality and time-to-deployment of the specification...
Test assertions provide a starting point for writing a conformance
test suite or an interoperability test suite for a specification that
can be used during implementation. They simplify the distribution of
the test development effort between different organizations while
maintaining consistent test quality."

"Test Assertions Part 2 - Test Assertion Markup Language Version 1.0"
defines a markup for writing test assertions, where Section 3 presents
the corresponding XML Schema for the vocabulary. Key markup language
elements include testAssertion, normativeSource (precise specification
requirements or normative statements that the test assertion addresses),
target (the implementation or part of an implementation that is the
object of a test assertion or test case, categorizing an implementation
or a part of an implementation of the referred specification, whether
a specific item or a category of items), prerequisite, predicate,
prescription, description, tag, var, report. etc.

"Test Assertions Guidelines" provides "guidelines and best practices
for writing test assertions along with mandatory and optional components
of a test assertion model. Its purpose is to help the reader understand
what test assertions are, their benefits, and most importantly, how
they are created. As you will discover, test assertions can be an
important and useful tool in promoting the quality of specifications,
test suites and implementations of specifications. You will learn that
there are many ways to create test assertions. By following the
guidelines in this document, you will learn how to develop well-defined
test assertions that can have useful purposes and applications such as
the starting point for a conformance test suite for a specification.
Experiences in developing test assertions will be shared, along with
lessons learned, helpful tricks and tools, hazards to avoid, and other
knowledge that may be helpful in crafting test assertions. This document
is limited to the essentials of test assertions..."

Windows Domain to Amazon EC2 Single Sign-On Access Solutions

David Chappell, the Principal of Chappell & Associates, US, has writtena whitepaper proposing several solutions for Single Sign-on (SSO) accessto applications deployed on Amazon EC2 from a Windows domain. InfoQexplored these solutions to understand what the benefits and tradeoffseach one presented.
The paper is: "Connecting to the Cloud: Providing Single Sign-On toAmazon EC2 Applications from an On-Premises Windows Domain." Excerpt:"Users hate having multiple passwords. Help desks hate multiple passwordstoo, since users forget them. Even IT operations people hate them,because managing and synchronizing multiple passwords is expensive andproblematic. Providing single sign-on (SSO) lets users log in just once,then access many applications without needing to enter more passwords.It can also make organizations more secure by reducing the number ofpasswords that must be maintained. And for vendors of Software as aService (SaaS), SSO can make their applications more attractive by lettingusers access them with less effort...
With the emergence of cloud platforms, new SSO challenges have appeared.For example, Amazon Web Services (AWS) provides the Amazon ElasticCompute Cloud (Amazon EC2). This technology lets a customer create AmazonMachine Images (AMIs) containing an operating system, applications, andmore. The customer can then launch instances of those AMIs (virtualmachines) to run applications on the Amazon cloud. Similarly, Microsoftprovides Windows Azure, which lets customers run Windows applications onMicrosoft's cloud. When an application running on a cloud platform needsto be accessed by a user in an on-premises Windows domain, giving thatuser single sign-on makes sense. Fortunately, there are several waysto do this..."
"SSO is an important feature to have when the number of on-premises andInternet accounts created by users grow to large numbers, making thetask of administering them increasingly difficult. This will likelyresult in more requests to software vendors for SSO support/solutionssince these make the users' lives simpler and reduce administration costs..."
http://www.infoq.com/news/2010/01/Windows-EC2-Single-Sign-OnSee also the white paper: http://download.microsoft.com/download/6/C/2/6C2DBA25-C4D3-474B-8977-E7D296FBFE71/EC2-Windows%20SSO%20v1%200--Chappell.pdf

W3C Invites Implementations of W3C XSD Component Designators

Members of the W3C XML Schema Working Group now invite implementationof the Candidate Recommendation specification "W3C XML Schema DefinitionLanguage (XSD): Component Designators." The Candidate Recommendationreview period for this document extends until 1-March-2010. Comments onthis document should be made in W3C's public installation of Bugzilla,specifying 'XML Schema' as the product.
A test suite is under development that identifies the set of canonicalschema component paths that should be generated for particular testschemas, and that relates certain non-canonical component paths to thecorresponding canonical schema component paths. The W3C XML SchemaWorking Group has agreed on the following specific CR exit criteria:(1) A test suite is available which provides cases for each axis andcomponent type, both for the XML Schema 1.0 component model and the XMLSchema 1.1 component model. (2) Generation or interpretation of canonicalschema component paths have been implemented successfully by at leasttwo independent implementations. (3) Generation or interpretation ofeach axis and component for non-canonical schema component paths hasbeen implemented successfully by at least two independent implementations.(4) The Working Group has responded formally to all issues raisedagainst this document during the Candidate Recommendation period.
"XML Schema: Component Designators" defines a scheme for identifying XMLSchema components as specified by 'XML Schema Part 1: Structures' and'XML Schema Part 2: Datatypes'. Part 1 of the W3C XML Schema DefinitionLanguage (XSD) recommendation defines these schema components, whereSection 2.2 lays out the inventory of schema components into three classes:(a) Primary components: simple and complex type definitions, attributedeclarations, and element declarations (b) Secondary components: attributeand model group definitions, identity-constraint definitions, and notationdeclarations (c) "Helper" components: annotations, model groups, particles,wildcards, and attribute uses In addition there is a master schemacomponent, the schema component representing the schema as a whole..."
http://www.w3.org/TR/2010/CR-xmlschema-ref-20100119/See also the W3C XML Schema Working Group: http://www.w3.org/XML/Schema

Principles for Standardized REST Authentication

"Working with the programming APIs for cloud providers and SaaS vendorshas taught me two things: (i) There are very few truly RESTfulprogramming APIs. (ii) Everyone feels the need to write a customauthentication protocol. I've programmed against more web servicesinterfaces than I can remember. In the last month alone, I've writtento web services APIs for Aria, AWS, enStratus, GoGrid, the RackspaceCloud, VMOps, Xero, and Zendesk. Each one requires a differentauthentication mechanism. Two of them (Aria and AWS) defy all logic andrequire different authentication mechanisms for different parts of theirrespective APIs. Let's end this here and now...
Here's a set of standards that I think should be in place for any RESTauthentication scheme. Here's the summary: (1) All REST API calls musttake place over HTTPS with a certificate signed by a trusted CA. Allclients must validate the certificate before interacting with the server.(2) All REST API calls should occur through dedicated API keys consistingof an identifying component and a shared, private secret. Systems mustallow a given customer to have multiple active API keys and de-activateindividual keys easily. (3) All REST queries must be authenticated bysigning the query parameters sorted in lower-case, alphabetical orderusing the private credential as the signing token. Signing should occurbefore URL encoding the query string...
This is a battle I know I am going to lose. After all, people stillcan't settle on being truly RESTful (just look at the AWS EC2 monstrosityof an API). Authentication is almost certainly a secondary consideration.If you are reading this post and just don't want to listen to mysuggestions, I plead with you to follow someone else's example and notroll your own authentication scheme..."
Dilip Krishnan (Blog 'RESTful API Authentication Schemes') provides asummary and encourages readers to weigh in on the recommendations.

http://broadcast.oreilly.com/2009/12/principles-for-standardized-rest-authentication.htmlSee also Dilip Krishnan: http://www.infoq.com/news/2010/01/rest-api-authentication-schemes

Call for Participation: W3C Workshop on the Next Steps for RDF

W3C is organizing a Workshop on the Next Steps for RDF around June,2010 as described in the Call for Participation. The deadline forposition papers is 29-March-2010. Each participant in the workshop mustbe associated with a position paper. W3C membership is not requiredto participate in the Workshop.

The goal of the workshop is to gather feedback from the Web communityon whether and, if yes, in which direction RDF should evolve. One ofthe main issues the Workshop should help deciding is whether it istimely for W3C to start a new RDF Working Group to define and standardizea next version of RDF.

While a new version of RDF may include changes in terms of features,semantics, and serialization syntax(es), backward compatibility is ofa paramount importance. Indeed, RDF has been deployed by tools andapplications, and the last few years have seen a significant uptake ofSemantic Web technologies and publication of billions of triples stemmingfrom public databases (see, eg, the Linked Open Data community). Itwould be, therefore, detrimental to this evolution if RDF was seen asunstable and if the validity of current application would be jeopardizedby a future evolution. As a consequence, with any changes of RDF,backward compatibility requirements should be formalized..."

Background: "The Resource Description Framework (RDF), including thegeneral concepts, its semantics, and an XML Serialization (RDF/XML),have been published in 2004. Since then, RDF has become the corearchitectural block of the Semantic Web, with a significant deploymentin terms of tools and applications. As a result of the R&D activitiesand the publication of newer standards like SPARQL, OWL, POWDER, orSKOS, but also due to the large scale deployment and applications, anumber of issues regarding RDF came to the fore. Some of those arerelated to features that are not present in the current version of RDFbut which became necessary in practice (e.g., the concept of NamedGraphs). Others result from the difficulties caused by the designdecisions taken in the course of defining the 2004 version of RDF (e.g.,restrictions whereby literals cannot appear as subjects). Definitionof newer standards have also revealed difficulties when applying thesemantics of RDF (e.g., the exact semantics of blank nodes for RIF andOWL, or the missing connection between URI-s and the RDF resourcesnamed by those URI-s for POWDER). New serializations formats (e.g., Turtle)have gained a significant support by the community, while thecomplications in RDF/XML syntax have created some difficulties in practiceas well as in the acceptance of RDF by a larger Web community. Finally,at present there is no standard programming API to manage RDF data;the need may arise to define such a standard either in a general,programming language independent way or for some of the importantlanguages (Javascript/ECMAscript, Java, Python, etc)..." More Info

Earth Observation Application Profile for OGC Catalogue Services

The Open Geospatial Consortium (OGC) has announced adoption andavailability of the "OGC EarthObservation (EO) Application Profile for the OGC Catalogue Services -- (CSW) Specification" Version 2.0.2. The EO-CSW standard will benefit a wide range of stakeholders involved in the provision and use of datagenerated by satellite-borne and aerial radar, optical and atmosphericsensors.

The EO-CSW standard describes a set of interfaces, bindings andencodings that can be implemented in catalog servers that dataproviders will use to publish collections of descriptive information(metadata) about Earth Observation data and services. Developers canalso implement this standard as part of Web clients that enable datausers and their applications to very efficiently search and exploitthese collections of Earth Observation data and services.

This specification is part of a set that describe services for managingEarth Observation (EO) data products. The services include collectionlevel, and product level catalogues, online-ordering for existing andfuture products, on-line access etc. These services are put intocontext in an overall document 'Best Practices for EO Products'. Theservices proposed are intended to support the identification (EO) dataproducts from previously identified data collections. In other words,the search and present of metadata from catalogues of EO data products.

The intent of the profile is to describe a cost effective interfacethat can be supported by many data providers (satellite operators,data distributors...), most of whom have existing (and relatively complex)facilities for the management of these data. The strategy is to reuseas far as possible the SOAP binding defined in the ISO ApplicationProfile, except the schemas defining the information model. To achievea cost effective interface, some choices will be limited by textualcomments. EO data product collections are usually structured to describedata products derived from a single sensor onboard a satellite or seriesof satellites. Products from different classes of sensors usually requirespecific product metadata. The following classes of products have beenidentified so far: radar, optical, atmospheric. The proposed approachis to identify a common set of elements grouped in a common (HMA)schema and extend this common schema to add the sensors specific metadata. More Info

W3C First Public Working Draft for Contacts API Specification

Members of the W3C Device APIs and Policy Working Group have publisheda First Public Working Draft for "The Contacts API" specification. Itdefines an API that provides access to a user's unified address book.
The API has been designed to meet requirements and use cases specifiedin the draft. Use cases: (1) Upload a set of contact details to a user'ssocial network; (2) Download a set of contact details from a user'ssocial network; (3) A user would like to keep their work address bookand personal address book seperate; (4) A user maintains a singleunified address book but would like to maintain groups of contactswithin that address book; (5) Use a web interface to manage contactdetails on both the user's device and the web; (6) A user would like toexport contacts from the one address book store and import them toanother address book store; (7) A user would like to be notified whenfriends have a birthday coming up; (8) A user would like his/hercontacts to update their own contact details via a mediating WebApplication and sync any changes to their current address book.

Details: "The Contacts API defines a high-level interface to provideaccess to the user's unified contact information, such as names,addresses and other contact information. The API itself is agnostic ofany underlying address book sources and data formats... The Contactsinterface exposes a database collecting contacts information, suchthat they may be created, found, read, updated, and deleted. Multipleaddress books, taken from different sources, can be represented withinthis unified address book interface...

The programmatic styles of the Contacts API and Geolocation API are verysimilar and because they both have the the same implied user experiencewithin the same implied User Agent the general security and privacyconsiderations of both APIs should remain common. The ability to alignthe security and privacy considerations of the Geolocation API withDAP APIs is important for the potential future benefit of making anysecurity and privacy mechanisms developed within the DAP WG applicableto the Geolocation API at some point in its own ongoing development...A conforming implementation of this specification must provide amechanism that protects the user's privacy and this mechanism shouldensure that no contact information is creatable, retrivable, updateableor removable without the user's express permission... More Info