The Cover PagesThe OASIS Cover Pages: The Online Resource for Markup Language Technologies
SEARCH | ABOUT | INDEX | NEWS | CORE STANDARDS | TECHNOLOGY REPORTS | EVENTS | LIBRARY
SEARCH
Advanced Search
ABOUT
Site Map
CP RSS Channel
Contact Us
Sponsoring CP
About Our Sponsors

NEWS
Cover Stories
Articles & Papers
Press Releases

CORE STANDARDS
XML
SGML
Schemas
XSL/XSLT/XPath
XLink
XML Query
CSS
SVG

TECHNOLOGY REPORTS
XML Applications
General Apps
Government Apps
Academic Apps

EVENTS
LIBRARY
Introductions
FAQs
Bibliography
Technology and Society
Semantics
Tech Topics
Software
Related Standards
Historic
Last modified: October 21, 2009
XML Daily Newslink. Wednesday, 21 October 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://sun.com



Public Review: Context/Value Association using Genericode 1.0
G. Ken Holman (ed), OASIS Public Review Draft

Members of the OASIS Code List Representation Technical Committee have published an approved Committee Draft of "Context/Value Association Using Genericode 1.0" for Public Review. Comments are invited through December 15, 2009.

The document "normatively describes the file format used in a 'context/value association' file (termed in short as 'a CVA file'). This file format is an XML vocabulary using address expressions to specify hierarchical document contexts and their associated constraints. A document context specifies one or more locations found in an XML document or other similarly structured hierarchy of information. A constraint is expressed as either an explicit expression evaluation or as a value inclusion in one or more controlled vocabularies of values. This file format specification assumes a controlled vocabulary of values is expressed in an external resource described by the OASIS Genericode standard --"Code List Representation (Genericode) 1.0."

Context/value association is useful in many aspects of working with an XML document using controlled vocabularies and other constraints. Two examples are (1) for the direction of user data entry in the creation of an XML document, ensuring that only valid values are proffered in a user interface selection such as a drop-down menu; and (2) for the validation of the correct use of valid values found in an XML document."

This re-titled specification replaces the draft "Schematron-based Value Validation Using Genericode" Version 0.1 Draft 1, which itself replaced the draft "UBL Methodology for Code List and Value Validation" Version 0.8 Draft 6, which itself replaced the "UBL Code List Value Validation Methodology" document that is directly referenced by name in the UBL 2.0 specification. This specification was originally a work product of the UBL Technical Committee before being transferred in toto to the Code List Representation Technical Committee... A 'code list' in its simplest form is just a set of strings that each represent an item or idea. The OASIS code list representation is not just a simple list of strings. It is a complete description of a code list, including not only the codes, but also alternate codes, descriptions of the codes, and any other data that is associated with the codes.

See also: the OASIS Code List Representation TC


Evaluating OAUTH's Suitability for SIP Authentication
Wolfgang Beck (ed), IETF Internet Draft

IETF has released a level -00 Internet Draft specification "Evaluating OAUTH's Suitability for SIP Authentication." Wikipedia: "The Session Initiation Protocol (SIP) is a signaling protocol, widely used for controlling multimedia communication sessions such as voice and video calls over Internet Protocol (IP). Other feasible application examples include video conferencing, streaming multimedia distribution, instant messaging, presence information and online games. The protocol can be used for creating, modifying and terminating two-party (unicast) or multiparty (multicast) sessions consisting of one or several media streams. The modification can involve changing addresses or ports, inviting more participants, adding or deleting media streams, etc..."

Abstract for the I-D: "The Open Authentication Protocol (OAUTH) provides a method for clients to access server resources on behalf of another party. This document evaluates OAUTH's suitability as an authentication mechanism for the Session Initiation Protocol (SIP) for use cases where web applications want to interact with SIP servers without sharing user credentials...

OAUTH is an authentication delegation protocol, that allows a client to access resources on a server on behalf of a resource owner. An example would be a printing service (OAUTH client) that wants to access photos on a photo sharing site (OAUTH server) on behalf of a user (OAUTH resource owner). The resource owner does not need to reveal her credentials to the OAUTH client. In a first phase, the client obtains token credentials from the server. Using these token credentials, the client can access resources on the server. Currently, this is only defined for HTTP requests. SIP, defined in RFC 3261, offers some resources that could be accessed by OAUTH clients as well: (1) The resource owner's identity can be used to make calls, change presence states, or send messages from a web application. (2) The presence state of the resource owner's contacts can be retrieved, displayed, or used in a web application. The resource protected by OAUTH is the resource owner's SIP account and its associated data. While it would be possible to use SIP as a way to obtain temporary OAUTH credentials and to authenticate a resource owner, this document focuses on the access of SIP resources.

OAuth: "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. OAuth consists of: (1) a mechanism for a user to authorize issuance of credentials which a third party can use to access resources on their behalf. (2) a mechanism for using the issued credential to authenticate HTTP requests (called 'signatures' in early OAuth).

See also: the IETF Open Authentication Protocol (OAuth) Working Group


Call for Implementations: Topic Maps Constraint Language (TMCL)
Lars Marius Garshol, ISO/IEC 13250 Topic Maps Announcement

Members of ISO/IEC JTC1/SC34 have published a new editor's draft for "ISO 19756: Topic Maps Constraint Language (TMCL)", together with updates in the TMCL issue tracker. "The intention is to give the Topic Maps community a few weeks to review this draft and comment on it, and for it to be discussed at the WG3 meeting in Leipzig. Following that, the editors intend to send it out for FDIS ballot. In other words: TMCL is just about finished. If you have comments on it, you need to get them in now... If you have been wondering when to implement TMCL the answer is that the time has come. We need implementations of this draft in order to verify that there are no mistakes or errors in the draft..."

"TMCL is a constraint language for Topic Maps, allowing definitions of Topic Maps ontologies and vocabularies to be written in a precise and machine-readable form. This makes it possible to validate a topic map against a TMCL schema to see if it conforms to the constraints in the schema, and also enables a number of other uses, such as schema-driven editors, object mappings, and so on.

TMCL is defined as a Topic Maps vocabulary consisting of a number topic, association, occurrence, and role types, identified by Published Subject Identifiers (PSIs), and defined using English prose. TMCL defines the concept of validation, by which a given topic map is valid according to a schema if it conforms to all the constraints in that schema and a number of additional constraints which apply to all topic maps independent of schema. TMCL does not have any syntax of its own, since it is defined simply as a Topic Maps vocabulary. However, a number of CTM templates are defined in this standard in order to facilitate authoring of TMCL schemas using CTM..."

See also: XML Topic Maps references


IETF KEYPROV Working Group Updates 'Symmetric Key Package Content Type'
Sean Turner and Russ Housley (eds), IETF Internet Draft

Members of the IETF KEYPROV Working Group, part of the IETF Security Area, have published a revised Internet Draft for the Standards Track specification "Symmetric Key Package Content Type." This document represents one of three principal specifications produced under the KEYPROV Working Group Charter to "develop the necessary protocols and data formats required to support provisioning and management of symmetric key authentication tokens, both proprietary and standards based."

This document "defines the symmetric key format content type. It is transport independent. The Cryptographic Message Syntax (RFC 5652) can be used to digitally sign, digest, authenticate, or encrypt this content type. The uses cases that motivated this work are elaborated in "Portable Symmetric Key Container (PSKC). Symmetric Key Package Content Type: The symmetric key package content type is used to transfer one or more plaintext symmetric keys from one party to another. A symmetric key package may be encapsulated in one or more CMS protecting content types. This content type must be Distinguished Encoding Rules (DER) encoded, per X.690...

Several attributes are defined to assist those using the symmetric key package defined in this document as part of a Portable Symmetric Key Container protocol (PSKC). The attributes fall in to three categories. The first category includes attributes that apply to a key package, and these attributes will generally appear in sKeyPkgAttrs. The second category includes attributes that apply to a particular key, and these attributes will generally appear in sKeyAttrs. The third category includes attributes that apply to a key policy. Of the attributes defined next, only the Key Identifier and Algorithm key attributes must be included. All other attributes are OPTIONAL. Like PSKC, the Symmetric Key Content Type supports extensibility. Primarily this is accomplished through the definition and inclusion of new attributes, but in some instances where the attribute contains more than one type the ASN.1 "..." extensibility mechanism is employed. A straightforward approach to conversion from XML types to ASN.1 is employed... Section 3.3 presents the Key Policy Attributes: Key policy attributes indicate a policy that can be attached to a key (e.g., Start Date, Expiry Date, Number of Transactions, Key Usage, PIN Policy). Appendix A (ASN.1 Module) appendix provides the normative ASN.1 definitions for the structures described in the specification using ASN.1 as defined in X.680 through X.683 (Extensible Markup Language (XML) element and attributes as defined in PSKC..."

See also: the IETF Provisioning of Symmetric Keys (KEYPROV) Working Group


W3C Publishes XForms 1.1 Standard
John M. Boyer (ed), W3C Technical Report

W3C has announced the approval of XForms 1.1 as a W3C Recommendation. It is a stable document and may be used as reference material or cited from another document. This document was produced by the W3C Forms Working Group as part of the Forms Activity within the W3C Interaction Domain. The working group has supplied a test suite (ZIP file file) and an implementation report demonstrating at least one implementation for each test of a feature and at least two interoperable implementations for each test of a required feature.

"XForms is an XML application that represents the next generation of forms for the Web. XForms is not a free-standing document type, but is intended to be integrated into other markup languages, such as XHTML, ODF, or SVG. An XForms-based web form gathers and processes XML data using an architecture that separates presentation, purpose and content. The underlying data of a form is organized into instances of data schema, although formal schema definitions are not required. An XForm allows processing of data to occur using three mechanisms: (1) a declarative model composed of formulae for data calculations and constraints, data type and other property declarations, and data submission parameters; (2) a view layer composed of intent-based user interface controls; (3) an imperative controller for orchestrating data manipulations, interactions between the model and view layers, and data submissions.

Thus, XForms accommodates form component reuse, fosters strong data type validation, eliminates unnecessary round-trips to the server, offers device independence and reduces the need for scripting. XForms 1.1 refines the XML processing platform introduced by XForms 1.0 by adding several new submission capabilities, action handlers, utility functions, user interface improvements, and helpful datatypes as well as a more powerful action processing facility, including conditional, iterated and background execution, the ability to manipulate data arbitrarily and to access event context information..."

See also: the XForms Implementation Report


The Simple Cloud API: Writing Portable, Interoperable Applications
Doug Tidwell, IBM developerWorks

"The recently announced Simple Cloud API provides a common API to a variety of cloud services. A collaborative effort by Zend, GoGrid, IBM, Microsoft, Nirvanix and Rackspace, the API allows you to write portable code that can interoperate with multiple cloud vendors. Best of all, the API allows you to use services specific to a particular vendor as necessary.

The flexibility and economic benefits of cloud computing have generated a tremendous amount of interest. As developers work with this technology, an obvious concern is vendor lock-in. Writing an application that makes the most of cloud computing is great. But what if that application locks you in to a single vendor? [...] One of the biggest risks with any new technology is building critical applications that lock you in to a particular vendor. Cloud computing can have significant economic benefits, but if using the cloud puts you at the mercy of a vendor's pricing strategy, that's a major concern...

The Simple Cloud API is a cooperative effort of several major cloud vendors to create a single, simple, interoperable API that works with many cloud services and providers. Work is under way to add support for more cloud services and cloud providers, and implementations of the API in languages other than PHP are in progress, as well. Cloud computing won't reach its full potential without openness and flexibility. The Simple Cloud API is an important tool for keeping the cloud open and your applications flexible..."

See also: the Simple Cloud API web site


The Cloud Beyond the Network
Ken Sinclair, AutomatedBuildings.com

"As more software and computer services move off-site, a look around suggests that the collaborative power of cloud computing has already begun to reign for those looking to harness real-time building information most efficiently. The goal of this article is to expose how the dotcom and dotorg are using the cloud to provide their products and services. The identification and use of these valuable industry cloud connectors is essential to propel our industry forward at warp speed so it can radically change to survive...

Cisco's Huijbregts: "Converging the performance of our physical and virtual environments will allow us to match or organically and effectively start to address the real needs of users of these environments. The network and the Cloud will allow the building industry to become more services-oriented instead of product- or building-oriented. Your building and its capabilities have become like an iPhone, and there is an open invitation to provide applications and services that can be pushed out to every standing structure in the world. It is happening already: consider ADR (demand response), remote building services and operations, energy monitoring and modeling (e.g., carbon calculations, trading), data mining, and benchmarking..."

David Wolins, CEO, Scientific Conservation, Inc. (SCI): "The process of collecting and mining data is at the heart of automated continuous commissioning (ACC). ACC uses access to the existing BAS and data from traceable external sources (such NOAA weather data) for this new class of analysis. The data is then used to create performance models of each piece of equipment to track actual (vs. design) operation. New modeling techniques have emerged to create models that persistently predict actual performance within a two percent margin of error. By leveraging these models, building operators and facility managers have a powerful means to diagnose and control component and system faults and anomalies..." We are all ambassadors of the cloud, and our future depends on our ability to provide working examples of using the cloud to connect to sustainability, conservation, and realtime energy information.


Sponsors

XML Daily Newslink and Cover Pages sponsored by:

IBM Corporationhttp://www.ibm.com
Microsoft Corporationhttp://www.microsoft.com
Oracle Corporationhttp://www.oracle.com
Primetonhttp://www.primeton.com
Sun Microsystems, Inc.http://sun.com

XML Daily Newslink: http://xml.coverpages.org/newsletter.html
Newsletter Archive: http://xml.coverpages.org/newsletterArchive.html
Newsletter subscribe: newsletter-subscribe@xml.coverpages.org
Newsletter unsubscribe: newsletter-unsubscribe@xml.coverpages.org
Newsletter help: newsletter-help@xml.coverpages.org
Cover Pages: http://xml.coverpages.org/



Hosted By
OASIS - Organization for the Advancement of Structured Information Standards

Sponsored By

IBM Corporation
ISIS Papyrus
Microsoft Corporation
Oracle Corporation

Primeton

XML Daily Newslink
Receive daily news updates from Managing Editor, Robin Cover.

 Newsletter Subscription
 Newsletter Archives
Globe Image

Document URI: http://xml.coverpages.org/newsletter/news2009-10-21.html  —  Legal stuff
Robin Cover, Editor: robin@oasis-open.org