Cover Pages: XML Daily Newslink: Friday, 12 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 Public Review for The State of ODF Interoperability Version 1.0
W3C Launches Decisions and Decision-Making Incubator Group
Anatomy of an Open Source Cloud: Infrastructure as a Service
Elastic Provisioning in the Cloud: Terracotta and Eucalyptus Integration
IETF Internet Draft: Security Requirements for HTTP
OASIS Blue Member Section: Open Standards for Smart Energy Grids
Proposed Recommendation Call for Review: XProc - An XML Pipeline Language
Expressing SNMP SMI Datatypes in XML Schema Definition Language
Dissecting the Consortium: A Uniquely Flexible Platform for Collaboration
Introduction to Pyjamas: Exploit the Synergy of GWT and Python
StoneGate SSL VPN Virtual Solution Supports OVF, SAML 2.0, and ADFS

OASIS Public Review for The State of ODF Interoperability Version 1.0
Robert Weir (editor), OASIS Committee Draft

Members of the OASIS Open Document Format Interoperability and Conformance (OIC) Technical Committee have submitted an approved Committee Draft The State of ODF Interoperability Version 1.0 for public review through May 08, 2010. OASIS encourages feedback from potential users, developers and others, whether OASIS members or not, for the sake of improving the interoperability and quality of this OASIS work. Interested parties are also invited to join the TC as it continues to further development of its specifications.

Overview: "OASIS OpenDocument Format (ODF) is a standard for office documents, including text documents, spreadsheets and presentations. ODF 1.0 was published in 2005, and ODF 1.1 was published in 2007. ODF 1.0 was also approved as ISO/IEC 26300:2006. The OASIS ODF Technical Committee1 is currently working on ODF 1.2.

The OASIS ODF Interoperability and Conformance (OIC) TC was created in October 2008 with the stated purpose 'to produce materials and host events that will help implementors create applications which conform the ODF standard and which are able to interoperate.'

The charter of the OIC TC also calls for it to periodically review the state of conformance and interoperability among ODF implementations, to report on 'overall trends in conformance and interoperability', to note 'areas of accomplishment as well as areas needing improvement' and to 'recommend prioritized activities for advancing the state of conformance and interoperability among ODF implementations.' This State of ODF Interoperability report is the first of the OIC TC's reports on interoperability, and as such provides an overview of the topic and discusses the baseline level of achievement. Future reports will focus on progress achieved beyond this baseline. This report discusses interoperability with respect to the OASIS OpenDocument Format (ODF) and notes specific areas where implementors might focus in order to improve interoperability among ODF-supporting applications.

W3C Launches Decisions and Decision-Making Incubator Group
Staff, W3C Announcement

"W3C is pleased to announce the creation of the Decisions and Decision- Making Incubator Group. The mission of this XG is to determine the requirements, use cases, and a representation of decisions and decision-making in a collaborative and networked environment suitable for leading to a potential standard for decision exchange, shared situational awareness, and measurement of the speed, effectiveness, and human factors of decision-making. Incubator Activity work is not on the W3C standards track but in many cases serves as a starting point for a future Working Group. The following W3C Members have sponsored the charter for this group: DISA, MITRE, and CNR. Jeff Waters and Don McGarry are the initial Decisions and Decision-Making Incubator Group co-Chairs.

Background: "Everyone makes important decisions in the daily accomplishment of their duties. The aggregate of these decisions constitutes the current state of their organization, and charts the course for our future direction and progress. In a sense, our decisions represent individuals and the organizations they represent. The effective representation, management, evaluation, and sharing of these decisions determines the success of the enterprise. Especially in a distributed, self-organizing, networked environment where digital media are the main interaction between members, distribution and tracking of decisions is particularly important for understanding what others are doing. Our decisions serve as information-work products; both as inputs and outputs. We use others decisions as references and our decisions become references to the decision process of others. The significant time and effort we spend converting our decisions into work products such as briefs, papers, proposals, and communication of our decisions in meetings, teleconferences, conversations, and emails, could be recaptured if we had a standard concise format for representing and sharing our decisions.

For these reasons, the members of the Decisions and Decision-Making Incubator are exploring and determining the requirements, use cases, and a potential standard format for representing our decisions efficiently and effectively in a collaborative networked environment for the purpose of information exchange for situational awareness. The Emergency Data Exchange Language Common Alerting Protocol (EDXL-CAP) family of standards is an example of the type and style of information exchange formats which are simple, useful, and understandable. What EDXL-CAP did for alerts, a common decision exchange protocol should do for decisions. However, to reach its full potential, the proposed decision format must be extended by the Semantic Web tools and standards to provide semantic interoperability and to provide a basis for reasoning that can ease development of advanced applications. Simplicity and understandability of decisions is particularly important in distributed, dynamic settings such as emergency management.

The group will maintain a wiki site containing relevant information. The deliverables will be a final report, a potential standard ontology, examples, and potentially prototype tools using the ontology. The vision of the final report outline includes: introduction, background and need, scope, use cases, requirements, issues and challenges, ontological patterns & solutions, sample decision ontology, representation formats, examples, candidate tools for instrumentation, examples, recommendations, and conclusion. In case the group decides that a particular technology is ripe for further standardization at the W3C, the group will consider preparing a W3C member submission and/or propose a W3C group charter to be considered by the W3C.

See also: the W3C Incubator Activity

Anatomy of an Open Source Cloud: Infrastructure as a Service
Tim Jones, IBM developerWorks

Cloud computing is no longer a technology on the cusp of breaking out but a valuable and important technology that is fundamentally changing the way we use and develop applications. Volumes could be written about the leadership role that open source is playing in the cloud and virtualization domain, but this article provided a short introduction to some of the popular and visible solutions available today. Whether you're looking to build a cloud based on your own requirements from individual pieces or simply want a cohesive solution that works out of the box, open source has you covered.

This article begins with an exploration of the core abstractions of cloud architectures (from Infrastructure as a Service IaaS), then moves beyond the building blocks to the more highly integrated solutions. Although not a requirement, virtualization provides unique benefits for building dynamically scalable architectures. In addition to scalability, virtualization introduces the ability to migrate virtual machines (VMs) between physical servers for the purposes of load balancing. The virtualization component is provided by a layer of software called a hypervisor (sometimes called a virtual machine monitor - VMM). This layer provides the ability to execute multiple operating systems (and their applications) simultaneously on a single physical machine. On the hypervisor is an object called a virtual machine that encapsulates the operating system, applications, and configuration. Optionally, device emulation can be provided in the hypervisor or as a VM. Finally, given the new dynamic nature of virtualization and the new capabilities it provides, new management schemes are needed. This management is best done in layers, considering local management at the server, as well as higher-level infrastructure management, providing the overall orchestration of the virtual environment.

As VMs are an aggregation of operating system, root file system, and configuration, the space is ripe for tool development. But to realize the full potential of VMs and tools, there must be a portable way to assemble them. The current approach, called the Open Virtualization Format (OVF) is a VM construction that is flexible, efficient, and portable. OVF wraps a virtual disk image in an XML wrapper that defines the configuration of the VM, including networking configuration, processor and memory requirements, and a variety of extensible metadata to further define the image and its platform needs. The key capability provided by OVF is the portability to distribute VMs in a hypervisor-agnostic manner..."

Elastic Provisioning in the Cloud: Terracotta and Eucalyptus Integration
Srini Penchikala, InfoQueue

"Terracotta recently announced a partnership with open source private cloud platform vendor Eucalyptus that allows the companies to provision private clouds on the Amazon AWS-compatible Eucalyptus cloud platform and take advantage of the elasticity and flexibility of the cloud. Eucalyptus is compatible with the Amazon AWS public cloud infrastructure and its design gives users the option of moving applications from on-premise Eucalyptus clouds to public clouds, and vice versa. It also supports 'hybrid' clouds allowing a composite of private (generally used to store private data) and public (provided by cloud service providers to offer customers the ability to deploy and consume services) cloud resources together to get the benefits of both deployment models. By addressing the data layer and to provision elastic cloud resources within internal infrastructure, Eucalyptus and Terracotta integration gives the organizations a way to build private clouds using commodity hardware and the virtualization technology."

Excerpts from comments of Ari Zilka (Terracotta) and Rich Wolsk (Eucalyptus): "We have both seen the need for the combined feature set we offer in a number of customer engagements, so working together made a lot of sense. Eucalyptus provides the provisioning and management framework for building and operating private clouds, and Terracotta ensures application data can elastically scale to meet the demands of this dynamically configured compute tier. The products are very complementary...

Developers using Eucalyptus as a cloud platform can immediately use the Terracotta scaling and caching frameworks to quickly build scalable web sites and Java applications, and deploy those applications to either Eucalyptus or to Amazon AWS. Developers already using Terracotta in Amazon's cloud can bring those applications and sites into a Eucalyptus-managed an on-premise cloud within their own data center..."

IETF Internet Draft: Security Requirements for HTTP
Jeff Hodges and Barry Leiba (eds), IETF Internet Draft

An updated version of the IETF Informational Internet Draft has been published documenting Security Requirements for HTTP. Recent Internet Engineering Steering Group (IESG) practice dictates that IETF protocols must specify mandatory-to-implement (MTI) security mechanisms, so that all conformant implementations share a common baseline. This document examines all widely deployed HTTP security technologies, and analyzes the trade-offs of each. The document examines the effects of applying security constraints to Web applications, documents the properties that result from each method, and will make Best Current Practice recommendations for HTTP security in a later document version.

Some existing HTTP Security Mechanisms include: Forms And Cookies, HTTP Access Authentication [Basic Authentication, Digest Authentication, Authentication Using Certificates in TLS, Other Access Authentication Schemes, Centrally-Issued Tickets, and Web Services security mechanisms. In addition to using TLS for client and/or server authentication, it is also very commonly used to protect the confidentiality and integrity of the HTTP session. For instance, both HTTP Basic authentication and Cookies are often protected against snooping by TLS. It should be noted that, in that case, TLS does not protect against a breach of the credential store at the server or against a keylogger or phishing interface at the client. TLS does not change the fact that Basic Authentication passwords are reusable and does not address that weakness.

Is is possible that HTTP will be revised in the future. "HTTP/1.1" (RFC 2616) and "Use and Interpretation of HTTP Version Numbers" (RFC 2145) define conformance requirements in relation to version numbers. In HTTP 1.1, all authentication mechanisms are optional, and no single transport substrate is specified. Any HTTP revision that adds a mandatory security mechanism or transport substrate will have to increment the HTTP version number appropriately. All widely used schemes are non-standard and/or proprietary..."

See also: Strict Transport Security

OASIS Blue Member Section: Open Standards for Smart Energy Grids
Staff, OASIS Announcement

OASIS has announced the formation of a new Member Section, OASIS Blue, which will bring together a variety of open standards projects related to energy, intelligent buildings, and natural resources. OASIS Blue will leverage the innovation of existing electronic commerce standards and the power of the Internet to achieve meaningful sustainability. An international effort, OASIS Blue incorporates work that has identified as a central deliverable for the U.S. government's strategic Smart Grid initiative. OASIS Blue welcomes suggestions for forming new Committees related to its mission.

The collaboration incoudes IBM, Constellation NewEnergy, CPower, EnerNOC, Grid Net, HP, NeuStar, TIBCO, U.S. Department of Defense, U.S. National Institute of Standards and Technology (NIST), and others.

Several Technical Committees will coordinate efforts under OASIS Blue. The Energy Interoperation Technical Committee defines standards for the collaborative and transactive use of energy within demand response and distributed energy resources. The Energy Market Information Exchange (eMIX) Technical Committee works on exchanging pricing information and product definitions in energy markets. The Open Building Information Exchange (oBIX) Technical Committee enables mechanical and electrical control systems in buildings to communicate with enterprise applications. Members of the oBIX TC plan to use the WS-Calendar specification to coordinate control system performance expectations with enterprise and smart grid activities.

David Chassin of Pacific Northwest National Laboratory, chair of the OASIS Blue Steering Committee: "OASIS Blue provides a safe, neutral environment where stakeholders can cooperate to define clear taxonomies and information-sharing protocols that will be recognized by the international standards community." Other OASIS Blue Steering Committee members include Steven Bushby of NIST, Bob Dolin of Echelon, Rik Drummond of the Drummond Group, Girish Ghatikar of Lawrence Berkeley National Laboratory, Francois Jammes of Schneider Electric, Arnaud Martens of Belgian SPF Finances, Dana K. "Deke" Smith of buildingSMART alliance, and Jane L. Snowdon, Ph.D., of IBM.

See also: the OASIS Blue MS web site

Proposed Recommendation Call for Review: XProc - An XML Pipeline Language
Norman Walsh, Alex Milowski, Henry S. Thompson (eds), W3C PR

The W3C XML Processing Model Working Group has published a Proposed Recommendation for XProc - An XML Pipeline Language, together with an Implementation Report for XProc: An XML Pipeline Language. Given that the changes to this draft do not affect the validity of that earlier implementation feedback, except in specific areas also now covered by more recent implementation feedback, the Working Group is now publishing this version as a Proposed Recommendation. The review period ends on 15-April-2010; members of the public are invited to send comments on this Proposed Recommendation to the 'public-xml-processing-model-comments' mailing list.

An XML Pipeline specifies a sequence of operations to be performed on a collection of XML input documents. Pipelines take zero or more XML documents as their input and produce zero or more XML documents as their output.

A pipeline consists of steps. Like pipelines, steps take zero or more XML documents as their inputs and produce zero or more XML documents as their outputs. The inputs of a step come from the web, from the pipeline document, from the inputs to the pipeline itself, or from the outputs of other steps in the pipeline. The outputs from a step are consumed by other steps, are outputs of the pipeline as a whole, or are discarded. There are three kinds of steps: atomic steps, compound steps, and multi-container steps. Atomic steps carry out single operations and have no substructure as far as the pipeline is concerned. Compound steps and multi-container steps control the execution of other steps, which they include in the form of one or more subpipelines.

The result of evaluating a pipeline (or subpipeline) is the result of evaluating the steps that it contains, in an order consistent with the connections between them. A pipeline must behave as if it evaluated each step each time it is encountered. Unless otherwise indicated, implementations must not assume that steps are functional (that is, that their outputs depend only on their inputs, options, and parameters) or side-effect free. The pattern of connections between steps will not always completely determine their order of evaluation. The evaluation order of steps not connected to one another is implementation-dependent... A typical step has zero or more inputs, from which it receives XML documents to process, zero or more outputs, to which it sends XML document results, and can have options and/or parameters. An atomic step is a step that performs a unit of XML processing, such as XInclude or transformation, and has no internal subpipeline. ] Atomic steps carry out fundamental XML operations and can perform arbitrary amounts of computation, but they are indivisible. An XSLT step, for example, performs XSLT processing; a Validate with XML Schema step validates one input with respect to some set of XML Schemas, etc..."

Expressing SNMP SMI Datatypes in XML Schema Definition Language
Mark Ellison and Bob Natale (eds), IETF Internet Draft

Members of the IETF Operations and Management Area Working Group Working Group have published a revised Internet Draft for Expressing SNMP SMI Datatypes in XML Schema Definition Language. The memo defines the IETF standard expression of Structure of Management Information (SMI) base datatypes in Extensible Markup Language (XML) Schema Definition (XSD) language. The primary objective of this memo is to enable the production of XML documents that are as faithful to the SMI as possible, using XSD as the validation mechanism.

Background: "Numerous use cases exist for expressing the management information described by SMI Management Information Base (MIB) modules in XML. Potential use cases reside both outside and within the traditional IETF network management community. For example, developers of some XML-based management applications may want to incorporate the rich set of data models provided by MIB modules. Developers of other XML-based management applications may want to access MIB module instrumentation via gateways to SNMP agents. Such applications benefit from the IETF standard mapping of SMI datatypes to XML datatypes via XSD.

MIB modules use SMIv2 (RFC 2578) to describe data models. For legacy MIB modules, SMIv1 (RFC 1155) was used. MIB data conveyed in variable bindings ('varbinds') within protocol data units (PDUs) of SNMP messages use the primitive, base datatypes defined by the SMI. The SMI allows for the creation of derivative datatypes, 'textual conventions' ('TCs'). A TC has a unique name, has a syntax that either refines or is a base SMI datatype and has relatively precise application-level semantics. TCs facilitate correct application-level handling of MIB data, improve readability of MIB modules by humans and support appropriate renderings of MIB data.

Values in varbinds corresponding to MIB objects defined with TC syntax are always encoded as the base SMI datatype underlying the TC syntax. Thus, the XSD mappings defined in this memo provide support for values of MIB objects defined with TC syntax as well as for values of MIB objects defined with base SMI syntax. Various independent schemes have been devised for expressing SMI datatypes in XSD. These schemes exhibit a degree of commonality, especially concerning numeric SMI datatypes, but these schemes also exhibit sufficient differences, especially concerning the non-numeric SMI datatypes, precluding uniformity of expression and general interoperability..."

Dissecting the Consortium: A Uniquely Flexible Platform for Collaboration
Andrew Updegrove, Standards Today Bulletin

"The opportunities and imperatives for collaborative action of all kinds among both for-profit and non-profit entities are growing as the world becomes more interconnected and problem solving becomes less susceptible to unilateral action. Those activities include research and development, information acquisition and sharing, group purchasing, open source software and content creation, applying for government grant funding, and much more.

At the same time, the rapid spread of Internet and Web accessibility allows collaborative activities to be undertaken more easily, and among more widely distributed participants, than has ever been possible before. But while the technology enabling collaboration has become ubiquitous, hard-won knowledge regarding best practices, successful governance structures, and appropriate legal frameworks for forming and managing successful collaborative activities has yet to be widely shared. As a result, those wishing to launch new collaborative projects may have difficulty finding reliable guidance in order to create structures appropriate to support their activities.

In this article, I provide a list of attributes that define and functions that are common to consortia, an overview of how their activities are typically staffed and supported, a comparative taxonomy of the existing legal/governance structures that have been created to address them, and an overview of the legal concerns which consortium founders need to address...

Multiple forces in the world today are converging to increase the ease and raise the value of collaboration in both the public and private sectors. Indeed, it is becoming increasingly common in business literature to find the opinion expressed that companies that fail to collaborate with their peers will be at a severe disadvantage to their more-willing competitors. In light of such opportunities, it is important for the founders of new collaborative projects, and their legal counsel, to be familiar with the types of frameworks available to serve as platforms for their endeavors, and to choose wisely before launching their initiatives. Happily, the consortium model, in all of its variations, provides a uniquely flexible and appropriate foundation upon which the collaborations of the future can be based..."

Introduction to Pyjamas: Exploit the Synergy of GWT and Python
Rick Hightower, IBM developerWorks

Pyjamas is a cool tool, or framework, for developing Asynchronous JavaScript and XML (Ajax) applications in Python. It's a versatile tool that you can use to write comprehensive applications without writing any JavaScript code. This series examines the myriad aspects of Pyjamas, and this first article explores Pyjamas's background and basic elements.

Google's Web Toolkit (GWT) lets you develop a Rich Internet Application (RIA) with Ajax, entirely in Java code. You can use the rich Java toolset (IDEs, refactoring, code completion, debuggers, and so on) to develop applications that can be deployed on all major Web browsers. With GWT you can write applications that behave like desktop applications but run in the browser. Pyjamas, a GWT port, is a tool and framework for developing Ajax applications in Python.

WebKit, XUL, and their ilk bring modern flair to desktop applications. Pyjamas brings WebKit to Python developers. With Webkit, Pyjamas becomes a cross-browser and cross-platform set of GUI widgets. You can develop widgets that will run anywhere WebKit and XUL run. The Pyjamas API-based application can live anywhere GWT applications would live. Plus, Pyjamas lets you write desktop applications built on top of WebKit and XUL. This is preferable to building applications on top of Qt or GTK because WebKit supports CSS, and it is used in many other places for reliable rendering (iPhone, Safari, Android, and so on).

With Pyjamas you create containers, then add widgets to the containers. The widgets can be labels, text fields, buttons, and so forth. Widgets, like buttons, have event handlers so you can listen for click events from the button..."

StoneGate SSL VPN Virtual Solution Supports OVF, SAML 2.0, and ADFS
Staff, Stonesoft Announcement

"Stonesoft has introduced three new products designed to provide secure mobile and remote access. This includes the new StoneGate SSL VPN Virtual solution, StoneGate SSL VPN 1.4 and StoneGate SSL-1060. The StoneGate SSL VPN Virtual solution is based on the Open Virtual Format (OVF) standard and provides multiple features that meet the needs of these environments, such as strong authentication, a flexible application portal and support for Federation ID standards such as SAML 2.0 and ADFS. The StoneGate SSL VPN Virtual Appliance is compatible with both VMware's ESX/ESXi 3.5 and 4.0 (vSphere) versions.

The StoneGate SSL VPN Virtual solution complements the company's StoneGate Virtual Firewall and Virtual IPS solutions for virtual and cloud computing environments. The new solution allows rapid deployment and implementation of secure mobile access to cloud computing.

As cloud computing becomes more prevalent in corporate business and virtualized data centers, there is a stronger need for secure access to corporate applications in the cloud. The StoneGate SSL VPN Virtual solution combines the need for granular access to the corporate web and legacy applications with the secure and authenticated profiling of users...

The StoneGate SSL VPN 1.4 offers organizations enhanced security provided with integrated mobile authentication methods, granular access control and a holistic view of access rights within a single integrated access policy. Additionally, the appliance provides easy management and administration of access control for all network users. Administrators can easily select the parameters, or a combination of parameters, that will grant or deny the access to applications. This includes sophisticated assessment and trace removal techniques to ensure that corporate security standards are enforced at all times for mobile and roaming users..."

See also: the OASIS SAML TC


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

Headlines

Sponsors