This issue of XML Daily Newslink is sponsored by:
Microsoft Corporation http://www.microsoft.com
- First Public IETF Working Draft: XML Encoding for OAuth 2
- OASIS Review: Symmetric Key Services Markup Language (SKSML) Version 1.0
- W3C Last Call Public Review for XHTML+RDFa 1.1
- Oracle Contributes Cloud Elemental Resource Model API to DMTF
- W3C Accepted as an ISO/IEC PAS Submitter on a 'Take it or Leave it' Basis
- Apache Axiom Development Team Releases Axiom Version 1.2.10
- XML Prague 2011 Call for Papers
First Public IETF Working Draft: XML Encoding for OAuth 2
Justin Richer (ed), IETF Internet Draft
IETF has published an initial level -00 Internet Draft for the document XML Encoding for OAuth 2. The editor notes that the memo "[supplies] XML encoding of JSON output values, for when you want to use OAuth with an XML API; it is my intent that this I-D (and the instance draft) become working group items." According to the Introduction: "The OAuth 2 Protocol makes use of JSON encoding for its structured return values, as defined by section 4.2 of the OAuth specification. However, JSON encoding is not always desirable, particularly when OAuth is being used as part of an XML API. This extension describes a means for the client to request a particular format and a method for the token endpoint to encode its return values as XML documents as opposed to the default JSON objects...
For transport, to select XML encoding, the client sends the optional parameter 'format' where the format parameter specifies the client's desired format for responses from the token endpoint. Valid values are "json" and "xml", though other extensions MAY define other valid values. If omitted, the parameter value defaults to "json" and behavior is as defined in OAuth 2. The server shall respond to a valid access grant containing an XML format request with an HTTP 200 response and content type of 'application/xml'.
Section 3 defines encodings for different parts of the JSON data model in XML equivalents. JSON objects SHALL be encoded by using XML Elements. The object itself SHALL be represented by the root elment of an XML subtree. All members of the object SHALL be represented by sub-elements of the root element. The key of the member pair SHALL be the node name of the XML Element, and the value of the member pair SHALL be encoded as the content of the XML Element...
Information Loss: This encoding scheme is intended to give a clear an intuitive mapping between OAuth and XML data structures. However, the mapping between the two formats is not exact and some information loss may occur, and round-trip translation between the two formats must not be depended upon: (1) Both strings and numbers (Strings and Numbers) in JSON are represented as CDATA in XML. Without type identifiers (Type Identifiers) there is no clear way to differentiate between the two in the XML encoding. (2) Arrays (Arrays) in JSON are represented by repeated elements in XML. There is therefore no reliable way to distinguish between a single-element array and a standalone string or number value in the XML encoding, as both would be encoded the same way...
OASIS Review: Symmetric Key Services Markup Language (SKSML) Version 1.0
Allen Schaaf, Anil Saldhana, Tomas Gustavsson (eds), OASIS Public Review Draft
Members of the OASIS Enterprise Key Management Infrastructure (EKMI) Technical Committee have released a Public Review Draft of the Symmetric Key Services Markup Language (SKSML) Version 1.0 with invitation for comments through November 20, 2010.
The document is a normative specification which defines the first version of the Symmetric Key Services Markup Language (SKSML), an XML-based messaging protocol, by which applications executing on computing devices may request and receive symmetric key-management services from centralized key-management servers, securely, over networks. Applications using SKSML are expected to either implement the SKSML protocol, or use a software library — called the Symmetric Key Client Library (SKCL) — that implements this protocol. SKSML messages are transported securely over standard HTTP using XML Security as defined in the W3C Recommendations (XML Signature and XML Encryption).
A confluence of events is causing many companies to consider encrypting sensitive data across many applications and platforms within their IT infrastructure: Breach Disclosure laws requiring companies that have suffered breaches on computers containing Personally Identifiable Information (PII); Industry-specific regulations such as the credit card industry's Payment Card Industry Data Security Standard; National laws such as the US' Health Insurance Portability and Accountability Act (HIPAA) and the European Union Directive... In a rush to provide solutions to the market, vendors have created many device-specific, platform-specific, database-specific and application-specific encryption and key-management tools. While these tools may be capable of performing their stated tasks adequately, a typical enterprise would have to deal with many encryption and key-management solutions to adequately protect sensitive data...
SKSML uses XML for encapsulating its requests and responses and can thus be used on any platform that supports XML. Using a scheme that concatenates unique Domain identifiers (Private Enterprise Numbers issued by the IANA), unique SKS Server identifiers within a domain and unique Key identifiers within an SKS server, SKSML creates Global Key Identifiers (GKID) that can uniquely identify symmetric keys across the internet. SKSML relies on XML Signature and XML Encryption. Relying on RSA cryptographic key-pairs and digital certificates, SKSML uses the digital signatures for authenticity and message-integrity, while using RSA-encryption for confidentiality. Using secure key-caching enabled through centrally-defined policies, SKSML supports the request and receipt of KeyCachePolicy elements by clients for the use of symmetric encryption keys even when the client is disconnected from the network and an SKS server. SKSML provides significant flexibility for defining policies on how symmetric encryption keys may be used by client applications..."
W3C Last Call Public Review for XHTML+RDFa 1.1
Shane McCarron (ed), W3C Technical Report
Members of the W3C RDFa Working Group have published a Last Call Working Draft for XHTML+RDFa 1.1: Support for RDFa via XHTML Modularization. The Last Call period ends 09-December-2010 and all feedback is welcome. A sample test harness is available. This set of tests is not intended to be exhaustive, but sers may find the tests to be useful examples of RDFa usage. An implementation report lists several implementations of this specification tested during the Candidate Recommendation period. A community-maintained Wiki page includes subsequent updates.
XHTML+RDFa 1.1 "is an XHTML Family markup language. It extends the XHTML 1.1 markup language with the attributes defined in RDFa Core 1.1. The document also defines an XHTML Modularization-compatible module for the RDFa Core attributes in both XML DTD and XML Schema formats. RDFa Core 1.1 itself defines attributes and syntax for embedding semantic markup in Host Languages. This document defines one such Host Language. The XHTML+RDFa 1.1 language is a superset of XHTML 1.1, integrating the attributes as defined in RDFa Core 1.1. This document is intended for authors who want to create XHTML Family documents that embed rich semantic markup.
Normative Appendix A includes an implementation of the XHTML+RDFa 1.1 language using XML Schema. It is implemented by combining the XHTML 1.1 Schema with the XHTML Metainformation Attribute Module. This is done by using a content model module, and then a driver module. There are direct links to the various files, and the files are also contained in the "Gzip'd TAR" and "Zip" archives...
Appendix B of the specification includes an implementation of the XHTML+RDFa 1.1 language as an XML DTD. It is implemented by combining the XHTML 1.1 DTD with the XHTML Metainformation Attribute Module..."
Oracle Contributes Cloud Elemental Resource Model API to DMTF
Staff, Oracle Announcement
Oracle has announced publication of the Oracle Cloud Resource Model Application Programming Interface (Oracle Cloud API) for managing cloud Further, Oracle has contributed the Oracle Cloud Elemental Resource Model API, a subset of the Oracle Cloud API, to the Distributed Management Task Force (DMTF) for consideration in DMTF's proposed Infrastructure as a Service (IaaS) Cloud API standard.
The Oracle Cloud Elemental Resource Model API encompasses the common elements that make up a cloud by specifying machines, storage volumes, and networks. The specification submitted to the DMTF describes how a machine can be provisioned from an image; how a volume can be attached to a machine; and how a machine can connect to a network. These basic building blocks are the basis to encourage open standardization in the industry.
The Oracle Cloud API follows the Representational State Transfer (REST) architecture style and uses HTTP methods to interact with the resources to achieve provisioning, associating, modifying, and retiring of entities. As a full resource model, the Oracle Cloud API also includes composite entities to facilitate system deployments and management, including assemblies, deployment and scalability groups... By leveraging virtualization, clustering and dynamic provisioning across all layers of the stack, the Oracle Cloud API helps ensure users can easily and efficiently manage their cloud-based resources to deliver better business agility and flexibility, high utilization, and reduced costs..."
From the specification Executive Summary: "This API enables an infrastructure provider to service their customers by allowing them to: (1) Browse templates that contain definitions and metadata of a logical unit of service; (2) Deploy a template into the cloud and form an IT topology on demand; (3) Perform operations (such as ONLINE, OFFLINE) on the resources; (4) Take backups of the resources. The RESTful (Representational State Transfer) API presented here focuses on the resource models and their attributes. Usage of the API is via the HTTP protocol. The GET, POST, PUT, and DELETE requests are all used. Resource representations documented here are in JSON..." [Note the earlier discussion by William Vambenepe.]
W3C Accepted as an ISO/IEC PAS Submitter on a 'Take it or Leave it' Basis
Andy Updegrove, ConsortiumInfo.org Standards Blog
"After sixteen years of working in parallel to the traditional standards infrastructure, the World Wide Web Consortium has taken an interesting decision: to begin submitting selected W3C Recommendations to that same system for endorsement. In doing so, it joins the small handful of consortia (seven, to be exact) that have applied for this option out of the hundreds of consortia currently active in the information and communications (ICT) to apply for that option.
If this process sounds vaguely familiar, that's likely because this is the same process that OASIS used to gain global endorsement of its OpenDocument Format (ODF). Microsoft took a similar, but procedurally distinct, route with OOXML, its competing document format, when it offered it to ECMA, which enjoys a special 'Fast Track' relationship with JTC1. What won't sound familiar is the conditions that the W3C has successfully included in its application to make submissions...
W3C established an unusual condition in its PAS Submitter Application. In effect, it demanded that its Recommendations be subject only to an 'up or down' vote within JTC1, and not be subject to modification. In reply to the question, 'What are the expectations of the proposer toward technical and editorial changes to the specification during the transposition process?' W3C unequivocally stated: 'At this point, W3C will only submit work completed and approved under the W3C technical process for approval by JTC 1 with the understanding that these W3C Recommendations will either be approved as-is by JTC 1 or rejected'...
Now that the W3C's PAS Submitter Application has been accepted, what will happen next? Will the relationship flower, or will the W3C, after a few trials, conclude that the benefits anticipated from the relationship have not manifested themselves? Will other consortia, after seeing the W3C's success in negotiating such favorable terms with JTC1, decide to follow its lead? And will JTC1 Steering Committees reach out to the consortia they compete with (as they sometimes do) to encourage them to become PAS submitters? We'll have to wait and see..."
Apache Axiom Development Team Releases Axiom Version 1.2.10
Andreas Veithen, Apache Software Foundation Announcement
The Apache Axiom Development Team has announced the release of Axiom Version 1.2.10. Apache Axiom "is a StAX-based, XML Infoset compliant object model which supports on-demand building of the object tree. It supports a novel 'pull-through' model which allows one to turn off the tree building and directly access the underlying pull event stream. It also has built in support for XML Optimized Packaging (XOP) and MTOM, the combination of which allows XML to carry binary data efficiently and in a transparent manner. The combination of these is an easy to use API with a very high performant architecture
Developed as part of Apache Axis2, Apache Axiom is the core of Apache Axis2. However, it is a pure standalone XML Infoset model with novel features and can be used independently of Apache Axis2.
Axiom 1.2.10 is a maintenance release that contains the several improvements. It features improved DOM compatibility and performance for DOOM. Users running Rampart on Axis2 1.5.2 may want to upgrade Axiom to 1.2.10 to take advantage of these improvements.
Axiom 1.2.10 also provides improved interoperability with various StAX implementation, in particular support for Woodstox 4.0. It is now possible to specify a configuration when requesting an XMLStreamWriter from StAXUtils, similarly to what is already possible for XMLStreamReader instances. This feature is required to support the next Abdera release (e.g., ABDERA-267)..."
XML Prague 2011 Call for Papers
Jirka Kosek, Conference Announcement
XML Prague 2011 is now welcoming submissions for presentations to be delivered at the next XML Prague event. The Call for Papers ends on January 5, 2011 (an extended abstract or full paper); notification of acceptance/rejection of paper will be sent to authors on January 24; a final paper is due for submission by February 5, 2011.
The XML Prague 2011 conference will be held on March 26-27, 2011 with the theme 'Web and XML'. Papers are invited on a range of applicable topics, including: (1) XML as new lingua franca for the Web. Why did it never happen? (2) HTML 5 and XHTML: breaking-up, coexistence or convergence? (3) JSON and XML love-in: how to enable Web Apps and Web Widgets? (4) XML Databases role in Web architecture. (5) XML and the emerging Semantic Web. (6) XML-based formats for electronic books.
All proposals will be submitted for review by a peer review panel made up of the XML Prague Program Committee. Submissions will be chosen based on interest, applicability, technical merit, and technical correctness... All submissions must be in English and paper should not exceed 15 pages in length. Papers for review can be submitted in any common format. However, we remind people that if your paper is accepted that we will be asking for the final version to be submitted in DocBook XML format...
All submissions must be made using the conference management system CMT. Microsoft's CMT "is a conference management service sponsored by Microsoft Research; it is a free service and its functionalities are fully accessible through its web based interfaces. CMT is capable of handling the complex workflow of an academic conference including submission of abstracts and papers; adding reviewers to the system; reviewer preferences, bidding and paper assignment; discussion phase for resolving conflicting reviews; notification of acceptance/rejection; camera-ready paper submissions... CMT enables the Program Committee chairs to easily export out a variety of reports in popular formats such as XML and Excel. CMT is currently a free service and its functionalities are fully accessible through its web based interfaces. CMT has been used extensively including large conferences such as ACM SIGMOD, ACM SIGKDD, VLDB, ACM SIGCHI, UAI, IEEE ICDE, STOC, SODA..."
XML Daily Newslink and Cover Pages sponsored by:
XML Daily Newslink: http://xml.coverpages.org/newsletter.html
Newsletter Archive: http://xml.coverpages.org/newsletterArchive.html
Newsletter subscribe: email@example.com
Newsletter unsubscribe: firstname.lastname@example.org
Newsletter help: email@example.com
Cover Pages: http://xml.coverpages.org/