Cover Pages: XML Daily Newslink: Monday, 30 March 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

Headlines

Charter Proposal: OASIS Energy Market Information Exchange (eMIX) TC
Bloor Research Update: Enterprise Data Protection
UBL 2.0 International Data Dictionary, Volume 1: Japanese, Italian, and Spanish
Revised Working Draft for Widgets 1.0: Digital Signatures
Expressing SNMP SMI Datatypes in XML Schema Definition Language
Connecting to the Cloud, Part 1: Leverage the Cloud in Applications

Charter Proposal: OASIS Energy Market Information Exchange (eMIX) TC
William Cox, Posting to OASIS 'smartgrid-interest' list

A draft charter proposal has been posted for an "OASIS Energy Market Information Exchange (eMIX) Technical Committee." Motivation: "Energy markets have been characterized by poor coordination of supply and demand. This failing has exacerbated the problems caused by rising energy demand. In particular, poor communications concerning times of peak use cause economic loss to energy suppliers and consumers. There are today a limited number of high demand periods (roughly ten days a year, and only a portion of those days) when the failure to manage peak demand causes immense costs to the provider of energy; and, if the demand cannot be met, expensive degradations of service to the consumer of energy. As the proportion of alternative energies on the grid rises, and more energy comes from unreliable sources, the frequency and scale of these problems will increase. Energy consumers can use a variety of technologies and strategies to shift energy use to times of lower demand and also to reduce use during peak periods. This shifting and reduction can reduce the need for new power plants, and transmission and distribution systems. These changes will reduce the overall costs of energy through greater economic efficiency. This process is called various names, including Demand Response (DR), demand shaping, and load shaping..." Proposed Scope: This TC will leverage existing work wherever feasible, and will produce specifications for interoperation consistent with architectural principles including symmetry, composability, service orientation, and aggregation. The TC will develop a data model and XML vocabulary to enable collaborative and transactive use of energy. Web services definitions, service definitions consistent with the OASIS SOA Reference Model, and XML vocabularies will be developed as needed for interoperable and standard exchange of: (1) Dynamic price information; (2) Bid information; (3) Time for use or availability; (4) Units and quantity to be traded; (5) Characteristics of what is to be traded; (6) Deal/Bid/Acceptance confirmation... From the posting: "This TC is intended to address the prices, market characteristics, and other information for energy trading, buying, and selling. I was inspired to start working on this from discussions in and around the NIST Building-to-Grid and Industry-to-Grid Domain Expert Working Groups, and continued interest from first round reviewers and from people attending GridEcon 2009 in Chicago. From my perspective as an enterprise software architect, this fits into a simple three layer stack with interoperation protocols (how to communicate) as the fundamental layer... I invite you to participate in a discussion on how to improve this charter, as well as the sorts of characteristics that are important to energy markets..."

See also: the posting

Enterprise Data Protection
Nigel Stanley, Bloor Research Market Update

Turmoil in international financial markets, coupled with multiple significant data leak events in both the public and private sectors, has placed enormous pressure on businesses to more actively manage their risk... End user organisations need to be reviewing their data loss and encryption strategies as a matter of urgency to prevent expensive and reputation-damaging incidents. This needs to be approached from a strategic viewpoint so that best use is made of budgets, personnel and systems. In February 2009, Voltage Security released enhancements to Voltage SecureMail. EMC, IBM, HP, and Thales with Brocade, LSI, NetApp, and Seagate announced they were forming an OASIS Key Management group in an effort to improve encryption key management... Encryption key management is still an issue as end user organisations still look for the silver bullet that will ease this complex task... The pressure on most businesses is very high as they contend with financial uncertainty, supply chain disruption and delayed or aborted buying decisions. Part of ongoing risk management must incorporate IT security and, in particular, the mitigation of data losses due to a disrupted employee base. Organisations still need to ensure that data does not leak from their systems and if it does it remains securely encrypted. Vendor solutions available today should be assessed, and partnerships created with the best vendor able to supply an Enterprise Data Protection product set in a realistic time frame that suits your particular organisation.

See also: KMIP references

UBL 2.0 International Data Dictionary, Volume 1: Japanese, Italian, and Spanish
Oriol B. Peris, Roberto Cisternino, Yukinori Saito (eds), OASIS Public Review Draft

Members of the OASIS Universal Business Language (UBL) Technical Committee have completed a Public Review Draft for "UBL 2.0 International Data Dictionary, Volume 1: Japanese, Italian, and Spanish." The review period extends through April 10, 2009. This International Data Dictionary (IDD) document provides informative translations of the UBL 2.0 data dictionary. UBL, the Universal Business Language, defines standard XML representations of common business documents such as purchase orders, invoices, and shipping notices. UBL 1.0, released as an OASIS Standard in November 2004, normatively defines over 600 standard business terms (represented as XML element names) that serve as the basis for eight basic standard XML business document types. These English-language names and their corresponding definitions constitute the UBL 1.0 data dictionary —not a separate publication, but simply a label for the collection of all the element names and definitions contained in the UBL 1.0 data model spreadsheets and in the XML schemas generated from these data models. As an informational aid for UBL users, UBL localization subcommittees subsequently translated all of the UBL 1.0 definitions into Chinese (traditional and simplified), Japanese, Korean, Spanish, and Italian. These translations were published in a single merged spreadsheet called the UBL 1.0 International Data Dictionary (IDD). With input from a number of government agencies in Europe and Asia, UBL 2.0, released as an OASIS Standard in December 2006, greatly expanded both the UBL document set and the library of UBL information items upon which they are based, adding terms and document types to support a broad range of additional functions needed for government procurement. The resulting UBL 2.0 data dictionary contains more than 1900 standard element names and their English-language definitions. The UBL localization subcommittees are now in the process of translating this much larger collection. As the translation effort is expected to take some time, the UBL Technical Committee is releasing the UBL 2.0 IDD in stages as the localization subcommittees complete their work in order to begin the public review that is an integral part of the OASIS specification process. This first release, Volume 1, contains translations of all the UBL 2.0 data definitions into Japanese, Italian, and Spanish; subsequent releases will add further translations as they become available... To essentialize content for users in specific language communities and facilitate revisions expected from public review, the current release does not attempt to merge the various translations it contains into a single spreadsheet as done in the UBL 1.0 IDD; instead, it retains the structure of the data models as published in UBL 2.0 itself. These are organized within each language directory under two subdirectories called common and maindoc, which are described in detail in Appendix D of the UBL 2.0 standard...

Revised Working Draft for Widgets 1.0: Digital Signatures
Frederick Hirsch, Marcos Caceres, Mark Priestley (eds), W3C Technical Report

Members of the W3C Web Applications Working Group have published a Working Draft for "Widgets 1.0: Digital Signatures." This document "defines a profile of the "XML Signature Syntax and Processing 1.1" specification to allow a widget package to be digitally signed. Widget authors and distributors can digitally sign widgets as a trust and quality assurance mechanism. Prior to instantiation, a user agent can use the digital signature to verify the integrity of the widget package and perform source authentication. This document specifies conformance requirements on both widget packages and user agents. A widget package can be signed by the author of the widget producing an XML DSIG v11 signature that cryptographically includes all of the file entries other than signature files. A widget package can also be signed by one or more distributors, with XML signatures that each cryptographically includes all of the non-signature file entries as well as any author signature. Digitally signing implies use of private key material only known by the signer, thus enabling verification of integrity and signature source." W3C "XML Signature Syntax and Processing Version 1.1" is a standards track document that "specifies XML digital signature processing rules and syntax. XML Signatures provide integrity, message authentication, and/or signer authentication services for data of any type, whether located within the XML that includes the signature or elsewhere. Integrity as a property means that "data has not been changed, destroyed, or lost in an unauthorized or accidental manner; a simple checksum can provide integrity from incidental changes in the data. Message authentication is similar but also protects against an active attack to alter the data whereby a change in the checksum is introduced so as to match the change in the data. Given an authentication code/protected checksum, message authentication ensures that tampering with both the data and checksum, so as to introduce changes while seemingly preserving integrity, are still detected. Signer authentication is a property to ensure that the identity of the signer is as claimed; a signature should indicate who signed a document, message or record, and should be difficult for another person to produce without authorization."

Expressing SNMP SMI Datatypes in XML Schema Definition Language
Bob Natale (ed), IETF Internet Draft

This 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 uses exist—both within and outside the traditional IETF network management community—for the expression of management information described in and accessible via SMI Management Information Base (MIB) modules as XML documents. For example, XML-based management applications which want to incorporate MIB modules as data models and/or to access MIB module instrumentation via gateways to SNMP agents will benefit from an IETF standard mapping of SMI datatypes to XML documents via XSD. The SMI allows for creation of derivative datatypes, termed "textual conventions" ("TCs"), each of which has a unique name, a syntax which is or refines a primitive SMI datatype, and relatively precise application-level semantics. TCs are used principally to facilitate correct application-level handling of MIB data and for the convenience of humans reading MIB modules and appropriately rendered MIB data output. Values in varbinds corresponding to MIB objects with TC syntaxes are always encoded as the primitive SMI datatype underlying the TC syntax. Thus, the XSD mappings defined in this memo will support MIB objects with TC syntax as well as those with base SMI syntax. Various independent schemes have been devised for expressing the SMI datatypes in XSD. These schemes have exhibited a degree of commonality (especially concerning the numeric SMI datatypes), but also sufficient differences (especially concerning the non-numeric SMI datatypes) to preclude uniformity and general interoperability. The primary purpose of this memo is to define a standard expression of SMI base datatypes in XSD to ensure fidelity, consistency, and general interoperability in this respect. Internet operators, management tool developers, and users will benefit from the wider selection of management tools and the greater degree of unified management—with attendant improvements in timeliness and accuracy of management information—which such a standard facilitates...

Connecting to the Cloud, Part 1: Leverage the Cloud in Applications
Mark O'Neill, IBM developerWorks

For years, the convention has been for network diagrams to use a cloud (a cumulus cloud, specifically) to represent the Internet. The cloud image indicated something amorphous, intangible, but still necessary to include in the diagram. Lines on the network did nothing but travel through the cloud, indicating data passing over the Internet. On security-focused diagrams, the line through the Cloud might include a padlock beside it, to indicate that the connection is secured. The cloud has now been promoted to a first-class actor in the network diagram itself. Applications can make use of the cloud in order to call out for added value, such as storage, queuing, and hosted applications. The applications themselves can also be hosted on the cloud. Rather than simply passing through the cloud, lines now connect to the cloud and use it as part of an application. This makes the cloud more tangible... In this three-part series, you examine how cloud computing manifests itself. The number of cloud computing providers is relatively small, each coming at the area from a different direction and providing different services. Programming language options vary from Python, to C#, to Java or other proprietary languages. Interfaces into the cloud vary also, though a lightweight REST interface is preferred, even if it is not currently offered by every cloud computing provider. Here in Part 1of the series, you look a hybrid example, that is, a private application that is augmented with cloud computing services and infrastructure. While examining the hybrid application, discover what cloud computing offers you. To do this, you examine its antecedents, and what the major players in cloud computing currently offer. Part 2 of this series will cover the development of the hybrid application designed in Part 1. Part 3 will focus on the security and governance issues of the solution.


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

Headlines

Sponsors