Cover Pages: XML Daily Newslink: Wednesday, 19 May 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:
Oracle Corporation http://www.oracle.com

Headlines

Last Call Working Drafts Published by W3C XML Security Working Group
Cal-WS Web Services API for Calendaring and Scheduling
OASIS WS-Calendar Version 1.0 Specification
CIARD RING: Infrastructure for Interoperability of Agricultural Research
XML Document Format for Indicating a Change in XCAP Resources
OpenFaces 3.0 Prerelease is JSF2.0 Compatible

Last Call Working Drafts Published by W3C XML Security Working Group
Frederick Hirsch, W3C Announcement

On behalf of the W3C XML Security Working Group, Frederick Hirsch (Chair) has announced the publication of three Last Call Working Drafts and a related specification XML Security Algorithm Cross-Reference. The Last Call public review period ends 10-June-2010. The W3C XML Security Working Group, chartered through June 2011, is taking next steps in developing the XML security specifications, reviewing use cases and requirements for the existing set of specifications, and creating an updated use case and requirements document. Based on these requirements, the Working Group is developing updates to the core XML Security specifications.

XML Encryption Syntax and Processing Version 1.1 specifies "a process for encrypting data and representing the result in XML. The data may be in a variety of formats, including octet streams and other unstructured data, or structured data formats such as XML documents, an XML element, or XML element content. The result of encrypting data is an XML Encryption element that contains or references the cipher data... When encrypting an XML element or element content the EncryptedData element replaces the element or content (respectively) in the encrypted version of the XML document. When encrypting arbitrary data (including entire XML documents), the EncryptedData element may become the root of a new XML document or become a child element in an application-chosen XML document..."

XML Signature Syntax and Processing Version 1.1 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. An XML Signature may be applied to the content of one or more resources. Enveloped or enveloping signatures are over data within the same XML document as the signature; detached signatures are over data external to the signature element. More specifically, this specification defines an XML signature element type and an XML signature application; conformance requirements for each are specified by way of schema definitions and prose respectively. This specification also includes other useful types that identify methods for referencing collections of resources, algorithms, and keying and management information. The XML Signature is a method of associating a key with referenced data (octets); it does not normatively specify how keys are associated with persons or institutions, nor the meaning of the data being referenced and signed. Consequently, while this specification is an important component of secure XML applications, it itself is not sufficient to address all application security/trust concerns, particularly with respect to using signed XML (or other data formats) as a basis of human-to-human communication and agreement.

XML Security Generic Hybrid Ciphers augments XML Encryption Version 1.1 specification by defining algorithms, XML types and elements necessary to enable use of generic hybrid ciphers in XML Security applications. Generic hybrid ciphers allow for a consistent treatment of asymmetric ciphers when encrypting data and consist of a key encapsulation algorithm with associated parameters and a data encapsulation algorithm with associated parameters. Further, the key encapsulation algorithms introduced in this specification have attractive security properties..." And XML Security Algorithm Cross-Reference summarizes "XML Security algorithm URI identifiers and the specifications associated with them... The various XML Security specifications have defined a number of algorithms of various types, while allowing and expecting additional algorithms to be defined later. Over time, these identifiers have been defined in a number of different specifications, including XML Signature, XML Encryption, RFCs and elsewhere. This makes it difficult for users of the XML Security specifications to know whether and where a URI for an algorithm of interest has been defined, and can lead to the use of incorrect URIs. The purpose of this document is to collect the various known URIs at the time of its publication and indicate the specifications in which they are defined in order to avoid confusion and errors..."

Cal-WS Web Services API for Calendaring and Scheduling
Dave Thewlis, CalConnect Announcement

On May 19, 2010, CalConnect Executive Director Dave Thewlis announced that CalConnect's XML Technical Committee had made available the Cal-WS Web Services API for Calendaring and Scheduling specification for 30-day Public Review and Comment. This draft [Cal-WS Draft V0.3, CD1004] represents the current draft of the XML TC's in-progress work document. This specification development work has been undertaken in conjunction with the NIST Smart Grid Standards Roadmap effort and with OASIS and the OASIS WS-Calendar Technical Committee. The Cal-WS specification is intended to form the web services section of the WS-Calendar standard. CalConnect encourages all interesting parties to review and comment on this work; the public review period for this draft will end on June 17, 2010.

The CalConnect (Calendaring and Scheduling Consortium) XML Technical Committee was chartered develop two specifications: (a) A specification for a two-way reference mapping of iCalendar to XML; (b) A core abstract calendaring API, and a concrete web services binding for that API, where initial design goal for this set of specifications is based on the NIST Smart Grid requirements for a web services calendaring and scheduling API. The main audience for these specifications is expected to be software developers. The "Cal-WS Web Services API for Calendaring and Scheduling" specification was intended to provide: (1) Base abstract calendaring API; (2) Create, retrieve, update, delete (CRUD) operations on the API; (3) Mapping of that API on to web services for WS-Calendar; (4) Associating the API with the iCal/xCal data models; (5) Demonstration of data model extensibility as needed by WS-Calendar.

Smart grid scenarios involve two main actors: a supplier and a consumer. Assumption #1: A smart grid consumer wants to schedule consumption of grid capacity to meet needs while minimizing cost or total energy use. Assumption #2: A smart grid supplier wants to schedule the available supply of grid capacity to meet consumer demand while minimizing outages and unused capacity... Basic methods include: CreateCalendar (creates a calendar with a unique id and optional display name and description), DeleteCalendar (deletes a calendar specified by a unique id), UpdateCalendar (updates display name or description for a calendar specified by a unique id), CreateItem (creates a calendar item on a specific calendar and using unique id specified for the calendar item), GetItems (Description: gets properties for one or more calendar items using a unique id specified for each calendar item), GetItemsInRange (gets calendar items from a specific calendar that fall within a specific time range, where results will include items where part of the event lies outside the time range), DeleteItem (deletes calendar items identified by unique ids from a specific calendar), UpdateItem (updates calendar items identified by unique ids on a specific calendar)...

Smart grid use cases illustrated in the specification include the following. Publish and query a rate schedule: 'A utility defines a rate schedule as a collection of events which include utility rates for a defined period of time; for example, different electricity rates can be set for peak and non-peak hours, where the utility creates events in the rate schedule and makes it available to be queried by devices on the grid.' Ask for Bids — negowatts: 'Consumer will reduce its demand by not using power it has already purchased if it receives an acceptable offer, e.g., offers can be made between 3 and 4 this afternoon (event) OR demand will be reduced between 4 and 4:30 p.m. this afternoon (event)'. Ask for Bids — load profile: 'Consumer wishes to buy power on a recurring basis with a specific usage profile, e.g., offers can be made between 3 and 4 this afternoon (event) OR load profile of several consecutive 30 minute intervals, each requiring different power (sequence)'. Submit Bid: 'Supplier agrees to supply power under certain conditions, e.g., consumer must reply by Friday at 4:30 p.m. (datetime) OR supplier can provide power between 12 a.m. and 10 a.m. every day this week (recurring event)..."

OASIS WS-Calendar Version 1.0 Specification
Toby Considine (ed), Informal Review Version

Members of the OASIS Web Services Calendar (WS-Calendar) Technical Committee have released a working draft for informal public comments: WS-Calendar Version 1.0, Working Draft 06. The WS-Calendar specification "describes a common set of message components for specifying schedules and intervals to coordinate activities between services. Web services definitions, service definitions consistent with the OASIS SOA Reference Model, and XML vocabularies for the interoperable and standard exchange of: (a) Schedules, including sequences of schedules; (b) Intervals, including sequences of intervals. The definition of the service performed to meet a schedule or interval depends on the market context in which it exists. It is not in scope for this TC to define those markets or services..." See sources in the OASIS Library, the TC's document repository for updates, and the local ZIP archive containing the PDF, Word (.doc), and HTML formats (file listing).

From the WS-Calendar specification Introduction: "One of the most fundamental components of negotiating services is agreeing when something should occur, and in auditing when they did occur. Short running services have traditionally been handled as if they were instantaneous, and thereby dodged this requirement through just-in-time requests. Longer running processes may require significant lead times. When multiple long-running services participate in the same business process, it may be more important to negotiate a common completion time than a common start time. Central coordination of such services reduces interoperability as it requires the coordinating agent to know the lead time of each service... Physical processes are now being coordinated by web services. Building systems and industrial processes are operated using oBIX, BACnet/WS, LON-WS, OPC XML, and a number of proprietary specifications including TAC-WS, Gridlogix EnNet, and MODBUS.NET. Energy use in buildings can be reduced while improving performance if building systems are coordinated with the schedules of the buildings occupants.

An increasing number of specifications envision synchronization of processes through mechanisms including broadcast scheduling. Efforts to build an intelligent power grid (or smart grid) rely on coordinating processes in homes, offices, and industry with projected and actual power availability, including different prices at different times. Two active OASIS Technical Committees require a common means to specify schedule and interval: Energy Interoperation (EITC) and Energy Market Information Exchange (EMIX). Emergency management coordinators wish to inform geographic regions of future events, such as a projected tornado touchdown, using EDXL. These efforts would benefit from a common standard for transmitting schedule and interval. For human interactions and human scheduling, the well-known iCalendar format is used. Today, there is no equivalent standard for web services. As an increasing number of physical processes are managed by web services, the lack of a similar standard for scheduling and coordination of services becomes critical.

The goal of WS-Calendar is to adapt the existing specifications for calendaring and apply them to develop a standard for how schedule and event information is passed between and within services. The standard should adopt the semantics and vocabulary of iCalendar for application to the completion of web service contracts. WS Services will be built on work done and ongoing in The Calendaring and Scheduling Consortium (CalConnect), in particular the xCal: The XML Format for iCalendar, Calendar Resource Schema [Schema for Representing Resources for Calendaring and Scheduling Services], and Cal-WS specifications. A calendar event without an associated contract is of little use. WS-Calendar will be a micro-specification, and then a micro-standard. WS-Calendar is unlikely to be used by itself. WS-Calendar will instead be used inside other specifications and standards, bringing a common scheduling function to diverse interactions in different domains..."

Late addition, from a public review announcement that appeared after the publication of this news blurb: The WS-Calendar TC members "believe the [draft WD-06] document to be essentially feature complete and stable. They have received late requests from those working on another Smart Grid Priority Action Plan to address the issues of Sequences of Operations and using the semantics of WS-Calendar to address them. The TC work plan is to address these issues as a profile on existing BPEL work during the informal comment period of 30 days (21 May 2010 through 20 June 2010). The rest of the document will be stable..."

CIARD RING: Infrastructure for Interoperability of Agricultural Research
Erna Klupacs, Agricultural Information Management Standards Announcement

"Creating integrated information services in agriculture giving access and adding value to information residing in distributed sources remains a major challenge. In distributed architectures, value added services by definition interface several information sources / services. Therefore value added services cannot be built without an awareness of what others have done: which sources are available, how to tap into them, how to exploit their semantics.

The Coherence in Information for Agricultural Research for Development (CIARD) Routemap to Information Nodes and Gateways (RING) is a portal offering an interlinked registry of existing information services in agriculture. The CIARD RING covers both information services and sources: in nowadays information architectures, the distinction between the two is very fluid. In the RING, the definition of "service" includes any form of providing information from one server instance (website, mail server, web services, XML archive...) to many clients (browsers, email clients, news readers, harvesters...) The services registered in the RING are described in details and categorized according to criteria that are relevant to the use of the service and its interoperability.

The RING categorizes and interlinks the featured services according to criteria such as: standards adopted, vocabulary used, technology used, protocols implemented, level of interoperability etc. In addition, it features detailed instructions on how the registered services can be "interoperated". The vision is that the RING will become the common global technical platform for the community of agricultural information professionals for accessing, sharing and exchanging information through web services.

This paper describes how the RING provides an infrastructure for enhancing interoperability of information sources and thus paves the way towards better accessibility of information through value-added and better targeted services..."

XML Document Format for Indicating a Change in XCAP Resources
Staff, Internet Engineering Task Force RFC

The Internet Engineering Steering Group (IESG) annnounced the publication of a new Standards Track Request for Comments #5874 (ISSN: 2070-1721): An Extensible Markup Language (XML) Document Format for Indicating a Change in XML Configuration Access Protocol (XCAP) Resources. This specification "defines a document format that can be used to indicate that a change has occurred in a document managed by the Extensible Markup Language (XML) Configuration Access Protocol (XCAP). This format reports which document has changed and its former and new entity tags. It can report the differences between versions of the document, using an XML patch format. It can report existing element and attribute content when versions of an XCAP server document change. XCAP diff documents can be delivered to diff clients using a number of means, including a Session Initiation Protocol (SIP) event package."

From the Introduction: "The Extensible Markup Language (XML) Configuration Access Protocol (XCAP) is a protocol that allows XCAP clients to manipulate XML documents stored on a server. These XML documents serve as configuration information for application protocols. As an example, resource list subscriptions (also known as presence lists) allow a SIP client to have a single SIP subscription to a list of users, where the list is maintained on a server. The server will obtain presence for those users and report it back to the SIP client. This application requires the server, called a Resource List Server (RLS), to have access to the list of presentities per RFC 2778. This list needs to be manipulated by XCAP clients so they can add and remove their friends as they desire.

Complexities arise when multiple XCAP clients attempt to simultaneously manipulate a document, such as a presence list. Frequently, an XCAP client will keep a copy of the current list in memory, so it can render it to users. However, if another XCAP client modifies the document, the cached version becomes stale. This modification event must be made known to all clients that have cached copies of the document, so that they can fetch the most recent one.

To resolve these problems, this document defines a data format that can convey the fact that an XML document managed by XCAP has changed. This data format is an XML document format, called an XCAP diff document. This format reports which document has changed and its former and new entity tags. It can report the differences between versions of the document, using an XML patch format (RFC 5261), which indicate how to transform the locally cached XCAP document from the version prior to the change to the version after it..."

OpenFaces 3.0 Prerelease is JSF2.0 Compatible
Gilad Manor, InfoQueue

TeamDev recently announced the pre-release of OpenFaces 3.0. The official release of the 3.0 version is expected in June later in 2010. This intermediate milestone is a JSF 2.0 compatible version of OpenFaces.

The new 3.0 release extends the existing library functionality with six new components: Complex filter criteria using the new CompositeFilter component; Layout components with the new LayeredPane component; The new functionality in the extended buttons; Command link with Ajax support; Checkbox components with Ajax support; Appearance customization.

Other enhancements were made to DataTable and TreeTable functionality. These components were enriched with the functions like vertical and horizontal content scrolling with frozen header/footer rows and columns, interactive drag&drop column reordering and column visibility customization. The API has been revised, enabling numerous filtering extensions..."

From the OpenFaces web site: "OpenFaces is an open-source library of AJAX-powered JSF components, an Ajax framework and a client-side validation framework. OpenFaces is based on the set of JSF components formerly known as QuipuKit. It contains fully revised codebase of QuipuKit and introduces many new components and features. OpenFaces is distributed under a dual license model. It means that you can choose between using the library under GNU Lesser General Public License (LGPL) or purchasing a commercial license..."

See also: the OpenFaces web site


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

Headlines

Sponsors