Cover Pages: XML Daily Newslink: Wednesday, 10 March 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:
ISIS Papyrus http://www.isis-papyrus.com/

Headlines

OASIS Opens Public Review for Test Assertions v1.0 Specifications
DMTF Submits Completed OVF Specification for ANSI/ISO Standardization
W3C Last Call Review for Web Security Context: User Interface Guidelines
NIST Publishes Open Vulnerability and Assessment Language (OVAL) Validation Program Test Requirements
IETF Publishes xCal: The XML Format for iCalendar
OGF Releases WS-Agreement Specification Version 1.0 Experience Document
OGC Announces Earth Observation Profile for Web-based Catalogue Services

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

DMTF Submits Completed OVF Specification for ANSI/ISO Standardization
Staff, Distributed Management Task Force Announcement

"DMTF has been busy extending and refining the Open Virtualization Format (OVF) specification. The organization recently completed version 1.1 of the specification and has submitted it for consideration as an ANSI and ISO standard. This is an important milestone for DMTF. The specification will be put through a number of tests to ensure it meets a complex system of checks and balances of reviews before it is adopted as an American and International standard. DMTF will be tracking the OVF specification as it makes its way toward becoming a national standard and then an international standard.

Originally proposed in September 2007, the OVF specification describes an open, secure, portable, efficient and extensible format for the packaging and distribution of software to run virtual machines. There are several new components that differentiate the OVF 1.1 specification from the original version, including: (1) Capability for file system-based images to increase flexibility at deployment time; (2) A property attribute to hide password values at the user interface; (3) Joliet extensions for ISO transport image; (4) Clarification of how the OVF manifest contain entries for individual file chunks; (5) Clarification of the referencing of manifest and certificate files from descriptor.

DMTF has also submitted OVF to the InterNational Committee for Information Technology Standards (INCITS) 'Fast-Track' process to develop it as an American National Standard at American National Standards Institute (ANSI). Once it is approved as an ANSI standard, OVF will be submitted to the International Standards Organization (ISO) for consideration as an international standardization.

DMTF Document Number DSP0243 contains Version 1.1.0 of the Open Virtualization Format Specification at DMTF Standard level. It was prepared by the System Virtualization, Partitioning, and Clustering Working Group of the DMTF. ANNEX C supplies the normative OVF XML Schema (XSD). A 'virtual machine' is the complete environment that supports the execution of guest software. 'Guest Software' is the software, stored on the virtual disks, that runs when a virtual machine is powered on; the guest is typically an operating system and some user-level applications and services. A virtual machine is a full encapsulation of the virtual hardware, virtual disks, and the metadata associated with it. Virtual machines allow multiplexing of the underlying physical machine through a software layer called a hypervisor. A 'virtual appliance' is a service delivered as a complete software stack installed on one or more virtual machines, where virtual appliance is typically expected to be delivered in an OVF package. An 'OVF package' is OVF XML descriptor file accompanied by zero or more files, and an 'OVF descriptor' is an OVF XML descriptor file..."

W3C Last Call Review for Web Security Context: User Interface Guidelines
Thomas Roessler and Anil Saldhana (eds), W3C Technical Report

Members of the W3C Web Security Context Working Group have published a Last Call Working Draft for Web Security Context: User Interface Guidelines. The specification defines guidelines and requirements for the presentation and communication of Web security context information to end-users. Publication of this Last Call Working Draft follows the 22-December-2009 Candidate Recommendation of this specification; changes are based on implementer feedback. A diff document details those changes. The purpose of this Last Call is to solicit community comment on these specific changes. The Working Group anticipates to request transition to Proposed Recommendation once this final Last Call is successfully concluded.

"The Working Group aims to demonstrate and test the WG's recommendations on usable and robust communication of security context information through implementations within the framework of one or more web user agents. The most likely web user agents to serve as platforms for such implementations are web browsers. To demonstrate that recommendations are sufficiently general and interoperable, we expect implementation in the context of at least two web user agents. We are targetting three types of testing of our recommendations: functional testing, robustness testing, and usability testing... All test development and testing is iterative. The recommendations may need to be modified on the basis of all three types of testing... Functional testing against the sample code and appropriate deployment configurations will verify that the recommendations can be translated to web user agent code, with no functional ill effects on the rest of the web user agent. Robustness testing will verify that the recommendations are robust against spoofing attacks. Usability testing will verify that the recommendations provide usable display of security context information...."

Overview: "Web user agents are now used to engage in a great variety and number of commercial and personal activities. Though the medium for these activities has changed, the potential for fraud has not. This Working Group is chartered to recommend user interfaces that help users make trust decisions on the Web. In-scope categories of technology and information include: (1) Web interactions: user interactions on the Web, using the HTTP and HTTPS protocols, where Web interactions involve other application-level protocols, including, e.g., SOAP or FTP; (2) User agents: a user agent is software to access Web content, including desktop graphical browsers, text browsers, voice browsers, mobile phones, multimedia players, plug-ins, and some software assistive technologies used in conjunction with browsers such as screen readers, screen magnifiers, and voice recognition software; (3) Entity identification, where a web browsing session is like a conversation, where the user converses with various entities, some known, and others newly encountered, and each resource the user interacts with is identified by a URI. (4) Third-party recommendation; (5) Historical browsing information...

The goal of this Working Group is to enable users to come to a better understanding of the context that they are operating in when making trust decisions on the Web; e.g., giving up passwords or other sensitive information to possibly malicious sites... Current Web user agents communicate only a small portion of available security context information to users in a way that is easily perceived and understood. Other context information that might be available to user agents and possibly helpful to users is either not presented, or presented in a way that is not understood by users, and hence useless or confusing. This information ranges from logotypes and company names and addresses that might be present in PKI certificates, to the user agent's memory of past activities..."

NIST Publishes Open Vulnerability and Assessment Language (OVAL) Validation Program Test Requirements
John Banghart, Stephen Quinn, David Waltermire (eds), NIST Report

An announcement from Pat O'Reilly of NIST's Computer Security Division reports on the publication of a Draft NIST Interagency Report (IR) 7669: Open Vulnerability and Assessment Language (OVAL) Validation Program Test Requirements. The report defines the requirements and associated test procedures necessary for products to achieve one or more Open Vulnerability and Assessment Language (OVAL) Validations. Validation is awarded based on testing a defined set of OVAL capabilities by independent laboratories that have been accredited for OVAL testing by the NIST National Voluntary Laboratory Accreditation Program (NVLAP).

Open Vulnerability and Assessment Language (OVAL) is an information security community standard to promote open and publicly available security content, and to standardize the transfer of this information across security tools and services. The OVAL Language is an XML specification for exchanging technical details on how to check systems for security-related software flaws, configuration issues, and patches.

The OVAL Language standardizes the three main steps of the assessment process: representing configuration information of systems for testing; analyzing the system for the presence of the specified machine state (vulnerability, configuration, patch state, etc.); and reporting the results of the assessment. In this way, OVAL enables open and publicly available security content and standardizes the transfer of this content across the entire spectrum of information security tools and services. OVAL is maintained by the MITRE Corporation...

The NIST OVAL Validation Program is designed to test the ability of products to use the features and functionality defined in the OVAL Language. An information technology (IT) product vendor can obtain one or more OVAL Validations for a product. These validations are based on the test requirements defined in this document, which cover four distinct but related validations based on product functionality..."

IETF Publishes xCal: The XML Format for iCalendar
Cyrus Daboo, Mike Douglass, and Steven Lees (eds), IETF Internet Draft

An IETF Internet Draft previously published under the title iCalendar XML Representation has been revised and issued under the new title xCal: The XML Format for iCalendar. An added Section 5 ("Handling Link Elements in XML and iCal") now recommends a preferred format for links in xCal documents, specifies an iCalendar extension for including links in iCalendar documents, and describes how to convert between the two formats.

"The iCalendar data format defined in IETF RFC 5545 is a widely deployed interchange format for calendaring and scheduling data. While many applications and services consume and generate calendar data, iCalendar is a specialized format that requires its own parser/generator. In contrast, XML-based formats are widely used for interoperability between applications, and the many tools that generate, parse, and manipulate XML make it easier to work with than iCalendar.

The purpose of this specification is to define 'xCal', an XML format that allows iCalendar data to be converted to XML, and then back to iCalendar, without losing any semantic meaning in the data. Anyone creating XML calendar data according to this specification will know that their data can be converted to a valid iCalendar representation as well. Two key design considerations are: (1) Round-tripping (converting an iCalendar instance to XML and back) will give the same result as the starting point. (2) Preserving the semantics of the iCalendar data. While a simple consumer can easily browse the calendar data in XML, a full understanding of iCalendar is still required in order to modify and/or fully comprehend the calendar data.

Handling Link Elements in XML and iCal: Both Atom (RFC 4287) and HTML use a link element to reference external information which is related in some way to the referencing document. iCalendar (RFC 5545) does not have such a mechanism. There are several common use cases where it would be useful for a calendar item to link to external structured data. For instance, it would be useful for an event item to denote the location of the event by referencing a vCard. Similarly, there may be a primary contact person for the event, and that person's vCard should be linked from the event as well. It is recommended therefore that calendar data in the xCal format use the Atom link element, as specified in RFC 5545 section 4.2.7, for linking to external related resources. The Relation Name 'location' designates a location for the referencing item. Typically the location will be in the form of a vCard, but it could be some other kind of document containing location information... A LINK extension property for iCalendar is used to reference external documents related to this calendar item. The property can appear on any iCalendar component, and the value of this property is a URI which references an external resource related to the component. Since the LINK parameter is specified in terms of the link element defined by RFC 5545, converting between the two is straightforward. When converting from iCalendar to xCal, simply take any parameters present and assign their values to the corresponding attribute on the link element. Any unknown extensions either in the iCalendar or xCal format MAY be ignored when converting to the other format..."

OGF Releases WS-Agreement Specification Version 1.0 Experience Document
Dominic Battré, Philipp Wieder, Wolfgang Ziegler (eds), OGF Technical Report

Open Grid Forum members have published WS-Agreement Specification Version 1.0 Experience Document (GFD-E.167) through the Grid Resource Allocation Agreement Protocol WG (GRAAP-WG). The document provides information to the Grid, Distributed Systems and Cloud Computing community about the experience with the WS-Agreement Specification Version 1.0. In describes existing implementations of the standard and compares them. OGF's GRAAP Working Group was chartered to produce a set of specifications and supporting documents which describe methods and means to establish Service Level Agreements between different entities in a distributed environment. GRAAP is also preparaing of the definition of an add-on to WS-Agreement v1.0 extending language and protocol to allow negotiation and re-negotiation of SLAs using WS-Agreement.

The "Web Services Agreement Specification (WS-Agreement)" defines a Web Services protocol for establishing agreement between two parties, such as between a service provider and consumer, using an extensible XML language for specifying the nature of the agreement, and agreement templates to facilitate discovery of compatible agreement parties. The specification consists of three parts which may be used in a composable manner: a schema for specifying an agreement, a schema for specifying an agreement template, and a set of port types and operations for managing agreement life-cycle, including creation, expiration, and monitoring of agreement states... An agreement between a service consumer and a service provider specifies one or more service level objectives both as expressions of requirements of the service consumer and assurances by the service provider on the availability of resources and/or on service qualities. For example, an agreement may provide assurances on the bounds of service response time and service availability. Alternatively, it may provide assurances on the availability of minimum resources such as memory, CPU MIPS, storage, etc.

The WS-Agreement Specification Version 1.0 Experience Document describes the "implementation experiences of independent implementations of WS-Agreement along with an overview of the projects that have implemented WS-Agreement so far. It also presents the features of WS-Agreement used by 8 of the implementations. Finally, the document contains information on set-up and results of an experiment where two independent implementations of WS-Agreement were used to mutually exchange templates describing jobs and create agreements... The document concludes with a discussion of areas, where extensions of the specification will be carried out in the future, namely extending the capabilities of the WS-Agreement negotiation protocol."

Concurrently, an initial draft document WS-Agreement Version Negotiation 1.0 has been released by OGF for comment. This document, edited by Oliver Waeldrich (Fraunhofer-Institute for Algorithms and Scientific Computing - SCAI) provides information to the Grid, Distributed Systems and Cloud Computing community about WS-Agreement Negotiation (version 1.0). In describes WS-Agreement Negotiation as an extension to the WS-Agreement Specification Version 1. "The negotiation is the process between an agreement initiator and an agreement responder of getting from an initial agreement template to an acceptable agreement offer. Negotiation of agreement offers is a non-binding process that allows two parties to exchange information and find a consensus for an acceptable agreement offer. A negotiation offer is a non-binding proposal for a potential agreement that one negotiation party makes to another. One or more negotiation offers made by one or more negotiating parties may precede a binding agreement offer as defined in the WS-Agreement specification. The offer describes the service a SLA to be negotiated is about and the associated quality of service in terms of guarantees. Additionally offers contain negotiation constraints that identify the negotiable terms as well as their value spaces..."

OGC Announces Earth Observation Profile for Web-based Catalogue Services
Staff, Open Geospatial Consortium Announcement

The Open Geospatial Consortium has announced adoption and availability of the OGC Catalogue Services Standard Extension Package for ebRIM Application Profile: Earth Observation Products, and also the related Geography Markup Language (GML) Application Schema for EO Products. Together, these standards, when implemented, will enable more efficient data publishing and discovery for a wide range of stakeholders who provide and use data generated by satellite-borne and aerial radar, optical and atmospheric sensors.

The OASIS standard ebRIM (Electronic business Registry Information Model) is the preferred cataloguing metamodel foundation for application profiles of the OpenGIS Catalogue Service Web (CS-W) Standard. The CS-W ebRIM EO standard describes a set of interfaces, bindings and encodings to be implemented in catalog servers so that data providers can publish descriptive information (metadata) about Earth Observation data. Developers can also implement this standard as part of Web clients that will enable data users and their applications to very efficiently search and exploit these collections of Earth Observation data.

OGC Catalogue Services Standard 2.0 Extension Package for ebRIM Application Profile: Earth Observation Products (OGC 06-131r6) is an OGC Implementation Standard of subtype Application Profile. This application profile standard "describes the interfaces, bindings and encodings required to discover, search and present metadata from catalogues of Earth Observation products. The profile presents a minimum specification for catalogue interoperability within the EO domain, with extensions for specific classes of data. It enables CSW-ebRIM catalogues to handle a variety of metadata pertaining to earth observation, like EO Products... EO data product collections are usually structured to describe data products derived from a single sensor onboard a satellite or series of satellites. Products from different classes of sensors usually require specific product metadata. The following classes of products have been identified so far: radar, optical, atmospheric."

OpenGIS Geography Markup Language (GML) Application Schema for Earth Observation Products (0GC 06-080r4) is an OGC Implementation Standard of subtype GML Application Schema. It "describes the encodings required to describe Earth Observation (EO) products from general to mission specific characteristics. The approach consists in modelling EO data product through a GML application schema. ISO definitions are specified for attributes where available, although not the full ISO schema is used for the structural definitions, which would lead to a less efficient overall structure. The general mechanism is to create a schema with a dedicated namespace for each level of specificity from a general description which is common to each EO Product to a restricted description for specific mission EO Product. Each level of specificity is an extension of the previous one..."


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

Headlines

Sponsors