Cover Pages: XML Daily Newslink: Tuesday, 31 July 2007

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:
SAP AG http://www.sap.com

Headlines

Web Services Addressing Metadata Becomes a W3C Proposed Recommendation
Extensible Messaging and Presence Protocol (XMPP): Core
IPsphere Framework Technical Specification Release 1
URI Declaration Versus Use
XML Security Next Steps Workshop and C14N11/XML Signature Interop Event
XACML References and Products
Plans for the Rich Web Application Backplane
Microsoft Wants Its HD Photo Technology to Be an Industry Standard
Java Message Service (JMS)

Web Services Addressing Metadata Becomes a W3C Proposed Recommendation
M. Gudgin, M. Hadley, T. Rogers, U. Yalcinalp (eds), W3C TR

Members of the W3C Web Services Addressing Working Group have released the "Web Services Addressing 1.0 - Metadata" specification as a Proposed Recommendation. Public comment is invited through 30-August-2007. The Working Group's implementation report demonstrates that the goals for interoperable implementations set in the Candidate Recommendation draft of this document were achieved with the exception of having only one implementation for '4.4.1 Explicit Association' and '4.4.2 Default Action Pattern' for WSDL 2.0. However, those sections are also supported in the interchange format of the WSDL Test Suite. The "Web Services Addressing 1.0 - Core" Recommendation defines a set of abstract properties and an XML Infoset (XML Information Set) representation of Web service endpoint references (EPRs) and to facilitate end-to-end addressing of endpoints in messages. The 'Web Services Addressing 1.0: Metadata' document defines how the abstract properties defined in "Web Services Addressing 1.0 - Core" are described using WSDL and how WS-Policy can be used to indicate the support of WS-Addressing by a Web service. WS-Addressing is designed to be able to work with WS-Policy 1.5, WSDL 2.0, and also (for backwards compatibility) with WSDL 1.1 described services.

Extensible Messaging and Presence Protocol (XMPP): Core
Peter Saint-Andre (ed), IETF Internet Draft

A communication from the IETF announces the availability of a new standards track draft specification in the on-line Internet Drafts directories: "Extensible Messaging and Presence Protocol (XMPP): Core." This 140-page document defines the core features of the Extensible Messaging and Presence Protocol (XMPP), a technology for streaming Extensible Markup Language (XML) elements in order to exchange structured information in close to real time between any two network-aware entities. XMPP provides a generalized, extensible framework for incrementally exchanging XML data, upon which a variety of applications can be built. The framework includes methods for stream setup and teardown, channel encryption, authentication of a client to a server and of one server to another server, and primitives for push-style messages, publication of network availability information ("presence"), and request-response interactions between any two XMPP entities. This document also specifies the format for XMPP addresses, which are fully internationalizable. The basic syntax and semantics of XMPP were developed originally within the Jabber open-source community, mainly in 1999. In late 2002, the XMPP Working Group was chartered with developing an adaptation of the core Jabber protocol that would be suitable as an IETF instant messaging (IM) and presence technology. As a result of work by the XMPP WG, RFC 3920 was published in October 2004. As a result of extensive implementation and deployment experience with XMPP since that time, as well as more formal interoperability testing, this document reflects consensus from the XMPP developer community regarding XMPP's core XML streaming technology. In particular, this document incorporates several backward-compatible changes from RFC 3920.

See also: XMPP references

IPsphere Framework Technical Specification Release 1
IPsphere Forum, Foundation Specification

The IPsphere Forum, "a nonprofit organization dedicated to unleashing the business and societal benefits of IP convergence," has announced the publication of its Release 1 Technical Specification. "Leveraging the strengths of Service Oriented Architectures (SOA), the IPsphere specification outlines a universal operational framework that offers transformational flexibility to its stakeholders and users. At the heart of this framework is the ability to abstract and compose telecommunications and IT resources into unlimited service possibilities via a standardized messaging structure." The target audience for this specification is Service Providers, IPsphere Framework Providers, Network Management System vendors, Operational Support System vendors, Element Management System vendors and other vendors such as network and IT equipment manufacturers. The document describes the technical specification of the IPsphere Framework, a framework for abstracting and composing multi-stakeholder telecommunications-based services both within and between service providers. Service abstraction describes the business and technical characteristics of a service and its constituent service elements. Service composition identifies and selects elements which satisfy these technical and business requirements. The IPsphere Service Structuring Stratum provides support for structuring, executing and assuring these services... The IPsphere Framework will form an agreed standard, which provides clear, well understood interfaces to critical business functions such as billing systems, ordering systems, technology management systems and other sub-systems. The IPsphere Framework also leverages the work of other open industrial standard bodies such as ITU-T, TMF, OASIS and IETF where applicable. The forum-approved revision of the IPsphere Framework specifications will be published into the public domain and open to implementation by any company, irrespective of its IPsphere Forum membership or non-membership status.

See also: the announcement

URI Declaration Versus Use
David Booth, Posting to W3C 'www-tag' Mailing List

When an HTTP URI is used to name something that is not a web page or web site (i.e., not an information resource), it is important to distinguish between the declaration of that URI as a name for a particular resource, and regular assertions about that resource. This difference is important to Web architecture and to other parties that wish to use the URI in assertions about the resource. The issue arises when another party attempts to dereference the URI in order to learn about the URI and its associated resource. The other party may wish to make use of the URI as a means of referring to the resource, without necessarily believing other assertions that are made about the resource. This difference is particularly confusing in RDF. Many programming languages distinguish between variable declarations and variable use, but RDF does not have a corresponding mechanism for URI declaration. Thus, when RDF statements are served from a URI, it may not be evident which of those RDF statements are intended to constitute a URI declaration and which are intended to be regular assertions about the resource. They all look the same. In fact, given an RDF triple, there is no way to determine, by examining the triple, whether that triple should be considered a part of the URI declaration or a regular assertion about the resource. It is up to the URI owner to indicate this distinction. This paper describes the distinction between URI declaration and use, and suggests some best practices. Even though this paper is written in terms of URIs, the concepts apply equally to IRIs. [Author's note: "Before discussing how to name what you get when you dereference a non-information resource URI, we should be clearer about what it is that we wish to name. In discussions thus far on this list, I think there has been insufficient differentiation between assertions that are part of a URI declaration, and normal assertions about a resource. This prompted me to write up several thoughts that I've had for some time that I hope will add value to this discussion... Comments on this document are invited."]

See also: the posting

XML Security Next Steps Workshop and C14N11/XML Signature Interop Event
Staff, W3C Announcement

W3C has issued a renewed call for papers in connection with the Workshop on Next Steps for XML Signature and XML Encryption, to be held September 25-26, 2007 in Mountain View, California, hosted by VeriSign. Position papers are due 14-August-2007. Workshop Chairs include Frederick Hirsch (Nokia; Chair, XML Security Specifications Maintenance Working Group, W3C) and Thomas Roessler (W3C Security Activity Lead). Workshop attendees will discuss next steps for the XML Signature and XML Encryption specifications and share their experiences implementing and developing these standards. Topics may include interoperability and robustness, performance, legal requirements for digital signature formats, and the impact of the evolving XML environment. The Workshop is expected to give its recommendations to the XML Security Specifications Maintenance Working Group. The Workshop is free free and open to all; however, submission of position papers is required of all participants. In conjunction with the workshop, the XML Security Specifications Maintenance Working Group will hold an interop test on 27-September-2007 to test C14N11 (Canonical XML 1.1) and XML Signature Core.

See also: Canonical XML 1.1

XACML References and Products
Anne Anderson (ed), OASIS Reference List

An updated (Version 1.83) document "XACML References and Products" has been published by members of the OASIS Extensible Access Control Markup Language (XACML) Technical Committee. Edited by Anne Anderson (Sun Microsystems), the document lists include publications, standards, products, and specifications that contain substantial information about XACML or make use of XACML in a substantial way. These are listed for the information of parties interested in XACML. The principal listing is a traditional bibliographic reference list. The 'Products and Deployments' section includes products and deployments that make substantial use of XACML and that have been announced publicly. Readers should keep in mind that this is an incomplete list of XACML deployments. For security reasons, enterprises are frequently unwilling to publicize the security mechanisms they use internally, and many deployments of XACML fall into this category. In other cases, XACML is used internal to products, but is not exposed, and the vendor has chosen not to disclose this internal use. The 'XACML Attribute Definitions' section includes links to specifications that define XACML Attributes. Note: By including these links, neither the XACML TC, nor OASIS itself, is endorsing, recommending, or guaranteeing the accuracy of the referenced statements, publications, standards, or products in any way. Neither the XACML TC nor OASIS itself guarantees the completeness or accuracy of the information in this list of references. This list may be modified at any time as further information about these or other publications and products becomes known.

See also: the OASIS XACML TC

Plans for the Rich Web Application Backplane
Martin Brown, IBM developerWorks

Both mashups and Ajax are now firmly entrenched in the Web landscape. Put them together and you have the makings for Rich Web applications. This article explains the Rich Web Application Backplane, currently a W3C Note, which is designed to bring standardization to the field, proving a set of common building blocks, or components, these applications tend to use. The purpose of the Rich Web Application Backplane is to provide and support the standards that will make it easier to develop Web applications in a way that more closely resembles existing standalone native applications. It will provide a more compatible and usable method to exchange information between the components. You define the roles of: (1) The submission system -- which controls interaction between Web client and Web server; (2) The data model—which holds information and provides methods for display; (3) The events—which control the interaction between the UI components, the data model components and the submission system. You should then be able to develop Web applications in any language and environment you chose and support the ready exchange of information between different components, irrespective of their source. Possibly the most interesting aspect of the Rich Application Backplane is that the process is largely designed to improve the current Web application infrastructure so that it more closely matches the traditional standalone application environment. The role of the XML data binding and events, and the process of adding life cycle methodologies to the deployment and execution of a Web application is very similar to the object-oriented approach and the Model-View-Controller (MVC) pattern. MVC components are designed for use in environments where a lot of user interface elements are displayed, and where the data handling interface and the viewable interface to that information can be developed without the two relying directly on each other. Instead the controller component is responsible for view to model updates, and often for updating the view based on the model data.

See also: the W3C Note

Microsoft Wants Its HD Photo Technology to Be an Industry Standard
Peter Galli, eWEEK

Microsoft is looking to get more of its technology certified as an industry standard and has submitted its HD Photo technology to the Joint Photographic Expert Group for a decision in that regard. JPEG, a working group of the International Organization for Standardization, has decided to introduce a new work item for the standardization of Microsoft's HD Photo file format, tentatively titled 'JPEG XR'; formal balloting of this work item is being submitted to the JPEG national delegations for approval. The ballot deadline for this new project is early October 2007, with the finalization and publication of the completed standard, if approved, expected to take up to a year after that... This technology would also help stimulate the ecosystem of editing and image manipulation software as well as the printing and display devices that would be created around these new capabilities, all of which customers would be willing to pay for, as the standard could be implemented in cell phones, digital still cameras, printers and other devices. Robert Rossi, Microsoft's principal program manager lead for emerging image and video: "Contrast ratios of 5,000:1 up to 30,000:1 are coming in the next three years. A tremendous range of brightness to darkness in the display is also coming, and images taken with JPEG XR will access the capabilities of these displays, whereas images encoded with JPEG won't. This will be a major benefit for user appreciation of digital photography..." The HD Photo technology was incubated in Microsoft Research some five years ago, where it was known as photon and developed by the Core Media Processing Team, before becoming part of the Windows Media family and being renamed Windows Media Photo. Another technology, the XML Paper Specification, is dedicated to printing and is also in the process of being standardized, while Microsoft is currently working on technology related to the display.

See also: the announcement

Java Message Service (JMS)
Eric J. Bruno, Dr. Dobb's Journal

This article examines messaging concepts and presents a sample JMS application. With distributed computing, many software components of one working system may be separated geographically. The need for these components to communicate is obvious, and this need drives many software design decisions. For instance, you might choose to use CORBA, SOAP, or message-oriented middleware for intercomponent communication. SOAP-based web-service development continues to grow, and uses XML and HTTP to remove the implementation details from remote procedure calls. But while SOAP has broken new ground in distributed computing, message-oriented middleware such as the Java Message Service (JMS) is still my tool of choice when reliability, performance, and security are top priorities. JMS is a specification that describes the properties and behavior of an information pipe for Java software. It also describes how Java client applications interact with the information pipe. JMS supports two main message paradigms: (1) Point-to-point (or queue-based) messaging; (2) Publish-and-subscribe (or topic-based) messaging. JMS can support the messaging concept of request-and-reply through both of these messaging domains. Writing JMS client applications is straightforward once you understand the basics. The power of JMS is in the ability to leverage built-in transaction management, and reliable message delivery, without knowing much more than the basics.

See also: Java Message Service (JMS)


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

Headlines

Sponsors