Cover Pages: XML Daily Newslink: Tuesday, 12 August 2008

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

W3C Invites Implementations for XQuery Update Facility 1.0
OASIS Working Draft: SAML V2.0 Metadata Interoperability Profile
Working Draft Update: SAML V2.0 Information Card Token Profile
Specification of 3GPP IM CN Subsystem XML Body Handling
W3C Report: TAG Work in Recent Months
Comparing LINQ-to-XML with XPath
Create a Maintainable Extensible XML Format
Versions in the Universal Business Language (UBL)

W3C Invites Implementations for XQuery Update Facility 1.0
D. Chamberlin, D. Florescu, J. Melton, J. Robie, J. Siméon (eds), W3C TR

W3C has issued a call for implementations in connection with the publication of "XQuery Update Facility 1.0" as a Candidate Recommendation. This specification defines an update facility that extends the XML Query language, XQuery. W3C XQuery is "a standardized language for combining documents, databases, Web pages and almost anything else. It is very widely implemented. It is powerful and easy to learn. XQuery is replacing proprietary middleware languages and Web Application development languages. XQuery is replacing complex Java or C++ programs with a few lines of code. XQuery is simpler to work with and easier to maintain than many other alternatives." The XQuery Update Facility provides expressions that can be used to make persistent changes to instances of the XQuery 1.0 and XPath 2.0 Data Model. Specifically, the XQuery Update Facility 1.0 provides facilities to perform any or all of the following operations on an XDM instance: Insertion of a node; Deletion of a node; Modification of a node by changing some of its properties while preserving its node identity; Creation of a modified copy of a node with a new node identity. The basic building block of XQuery is the expression. XQuery 1.0 provides several kinds of expressions that can be composed with each other in arbitrary ways. An XQuery 1.0 expression takes zero or more XDM instances as input and returns an XDM instance as a result. In XQuery 1.0, an expression never modifies the state of an existing node; however, constructor expressions create new nodes with new node identities. XQuery Update Facility 1.0 introduces a new category of expression called an updating expression, which can potentially modify the state of an existing node... The XML Query Working Group intends to submit this document for consideration as a W3C Proposed Recommendation as soon as the following conditions are met: (1) A test suite is available that tests each identified XQuery Update Facility feature, both required and optional. (2) 'Minimal Conformance' to this specification has been demonstrated by at least two distinct implementations, at least one of which uses the XQuery human-readable syntax defined in this specification. (3) The Working Group has responded formally to all issues raised during the CR period against this document. The document will remain a Candidate Recommendation until at least 20-June-2008.

OASIS Working Draft: SAML V2.0 Metadata Interoperability Profile
Scott Cantor (ed), Contribution to OASIS Security Services (SAML) TC

A Working Draft Version 01 specification for a "SAML V2.0 Metadata Interoperability Profile" has been submitted to the OASIS Security Services (SAML) TC. "This profile describes a set of rules for SAML metadata producers and consumers to follow such that federated relationships can be interoperably provisioned, and controlled at runtime in a secure, understandable, and self-contained fashion. The SAML V2.0 metadata specification ("Metadata for the OASIS Security Assertion Markup Language V2.0") defines an XML schema and a set of basic processing rules intended to facilitate the use of SAML profiles, and generally any profile or specification involving SAML. Practical experience has shown that the most complex aspects of implementing most SAML profiles, and obtaining interoperability between such implementations, are in the areas of provisioning federated relationships between deployments, and establishing the validity of cryptographic signatures and handshakes. Because the metadata specification was largely intended to solve those exact problems, additional profiling is needed to improve and clarify the use of metadata in addressing those aspects of deployment. This profile is the product of the implementation experience of several SAML solution providers and has been widely deployed and successfully used in furtherance of the goal of scaling deployment beyond small numbers into the hundreds and thousands of sites, without sacrificing security. Experience has shown that the most frustrating part of using SAML (and many similar technologies) is that products approach the use of cryptography and trust in wildly inconsistent ways, and often the libraries that such products depend on do the same in their own domains. Key management is hard, and often relies on complicated tools with cryptic output. Standards only help insofar as they can be understood and widely implemented; this has generally not occurred above a basic level of cryptographic correctness. A formal PKI is a tremendously complex, and some would say intractable, goal; it could be argued that SAML itself is a reaction to this. Often, the security of deployments is based on a presumption that required practices like revocation checking are being performed, when in fact they are not. The purpose of this profile is to guarantee that in a correct implementation, all security considerations not deriving from the particular cryptography used (i.e. algorithm strength, key sizes) can be isolated to metadata exchange and acceptance, and not affect the runtime processing of messages.

Working Draft Update: SAML V2.0 Information Card Token Profile
Scott Cantor (ed), OASIS SAML TC Working Draft

A revised version of the "SAML V2.0 Information Card Token Profile" has been contributed to the OASIS SAML TC as Working Draft Version 02. This Draft version 02 incorporates feedback, refines the Recipient/Audience rules, adds a signing requirement, and enumerates assertion validation processing rules. "This profile describes a set of rules for identity providers and relying parties to follow when using SAML V2.0 assertions as managed information card security tokens, so that interoperability and security is achieved commensurate with other SAML authentication profiles... Microsoft has defined a set of profiles for acquring and delivering security tokens, collectively referred to as "Information Card" technology. These profiles are agnostic with respect to the format and semantics of a security token, but interoperability between issuing and relying parties cannot be achieved without additional rules governing the creation and use of the tokens exchanged. This document describes a set of rules for the use of SAML V2.0 assertions, as defined in SAML2 Core, as security tokens within the Information Card architecture... Identity providers and relying parties employing the Identity Selector Interoperability Profile (ISIP) [A. Nanda, Identity Selector Interoperability Profile V1.0, Microsoft, April 2007] to request and exchange security tokens are able to use arbitrary token formats, provided there is agreement on the token's syntax and semantics, and a way to connect the token's content to the supported protocol features. This profile provides a set of requirements and guidelines for the use of SAML V2.0 assertions as security tokens that, where possible, emulates existing SAML V2.0 authentication profiles so as to limit the amount of new work that must be done by existing software to support the use of Information Cards. It also provides for the use of SAML assertions in this new context that is safe, and consistent with best practices in similar contexts. This profile does not seek to alter the required behavior of existing identity selector software, or conflict with the profiles defined by ISIP...

Specification of 3GPP IM CN Subsystem XML Body Handling
John-Luc Bakker (ed), IETF Internet Draft

The 3rd Generation Partnership Project (3GPP) is specifying the IP multimedia subsystem (IMS) where SIP is the protocol used to establish media sessions across different participants. The Session Initiation Protocol (SIP) "is a signalling protocol, widely used for setting up and tearing down multimedia communication sessions such as voice and video calls over the Internet. Other feasible application examples include video conferencing, streaming multimedia distribution, instant messaging, presence information and online games. In November 2000, SIP was accepted as a 3GPP signaling protocol and permanent element of the IMS architecture for IP based streaming multimedia services in cellular systems." In the IMS it is possible that a UA attempts to place an emergency call when the IMS network does not support emergency services. The edge proxy detects the emergency call and can redirect the UE using a SIP 380 (Alternative Service) to place the emergency call using another domain (e.g., using a Circuit Switched network). This document registers new disposition-types for the Content-Disposition header that apply to the 'application/3gpp-ims+xml' body used by 3GPP. The applicability of these content-disposition values are limited to 3GPP IMS. The 'application/3gpp-ims+xml' body has the following two distinct uses: (1) for redirecting the emergency session to use a different domain (e.g., using a Circuit Switched call), and (2) for delivering user profile specific information from the SIP registrar to an Application Server. New disposition-types for the Content-Disposition header can only be registered with IANA according to procedures defined in Section 9 of RFC 2183. This document therefore registers new disposition-types for the Content- Disposition header to address specific requirements of the IMS. The new disposition-types may not be applicable to the general Internet. The new disposition types are applicable to the "application/3gpp-ims+xml" MIME type... This document makes certain assumptions regarding network topology and the existence of transitive trust. These assumptions are generally not applicable in the Internet as a whole. The mechanism specified here was designed to satisfy the requirements specified by the 3rd Generation Partnership Project for IP multimedia subsystem (IMS) for which either no general-purpose solution was found, where insufficient operational experience was available to understand if a general solution is needed, or where a more general solution is not yet mature. Note: Numerous 3GPP IMS- and UMTS-related specifications have Extensible Markup Language (XML) definitions. 3GPP Organizational Partners include ARIB, CCSA, ETSI, ATIS, TTA, and TTC.

W3C Report: TAG Work in Recent Months
Dan Connolly, W3C Communication

An August 2008 report has been prepared by Dan Connolly (W3C TAG Team Contact) on behalf of the W3C Technical Architecture Group (TAG). The W3C Technical Architecture Group, originally chartered in 2001, was formed to "document and build consensus around principles of Web architecture and to interpret and clarify these principles when necessary... Web architecture refers to the underlying principles that should be adhered to by all Web components, whether developed inside or outside W3C. The architecture captures principles that affect such things as understandability, interoperability, scalability, accessibility, and internationalization." Three TAG participants are appointed by the W3C Director and five TAG participants are elected by the Advisory Committee. In the August 2008, Connolly summarizes TAG discussions in three areas: (1) Formats: HTML and ARIA, Namespace Documents. "As design of Accessible Rich Internet Applications (WAI-ARIA) matured in the WAI Protocols and Formats Working Group (PFWG) and work started on integration with host languages, especially HTML, the TAG noted the use of an ad-hoc namespace mechanism: an aria- prefix on a collection of attributes... The TAG published a finding on Associating Resources with Namespaces, which addresses issue namespaceDocument-8. The finding suggests conventions, from ordinary HTML to dialects using RDDL and GRDDL to RDF, OWL, and XML Schema, for documenting namespaces and for linking associated resources... While still in draft form, The Self-Describing Web was updated 12 May 2008; it discusses features of the Web that support reliable, ad hoc discovery of information, including formats such as Atom, RDFa, GRDDL, XML, and RDF. Work continued on ISSUE-41, What are good practices for designing extensible XML languages and for handling versioning?. The 20-May-2008 draft of Extending and Versioning Languages: Compatibility Strategies incorporates a number of reviews comments..." (2) Protocols: widget packaging, HTTP scalability, linking. The TAG has opened a new issue, uriBasedPackageAccess-61, in response to a request for support from the Web Applications Formats (WAF) community to consider URI based access and reference to items within a web accessible package... In a 19 June discussion of issue scalabilityOfURIAccess-58, the TAG encouraged use of XML catalogs as a caching mechanism to mitigate the load that automated access to DTDs and schemas put on the W3C web site... Protocol support for linking, e.g. from non-hypertext formats, was in early drafts of HTTP but did not receive enough implementation experience to be ratified in RFC 2616 in June 1999. An HTTP Header Linking draft of 14 March 'clarifies the status of the Link HTTP header and attempts to consolidate link relations in a single registry.'.. Also following our May meeting in Bristol, we invited comment on the 2 June draft of Passwords in the Clear, especially from the HTML Working Group and the Web Security Context Working Group." (3) Naming: XRIs. The TAG is working on comparing HTTP and DNS to other approaches to persistent naming such as 'info:' and 'xri:' under issue issue URNsAndRegistries-50. While the URNs, Namespaces and Registries draft has been preempted by other work since the last update of August 2006, the TAG discovered a 31 May deadline on a ballot to Approve XRI Resolution v2.0 as an OASIS Standard and summarized its position: TAG recommends against XRI. In an attempt to facilitate dialog after this somewhat awkward step, the TAG and the OASIS XRI TC held a 3-July-2008 joint meeting and continue the discussion by email in www-tag with the goals of improving understanding of our respective positions and to publically record points of agreement and if necessary irresolvable disagreement."

Comparing LINQ-to-XML with XPath
Paul Kimmel, DDJ

XPath is an open standard for querying and transforming XML documents; however, it is a completely different technology than C# programming, which you [may] already know. With LINQ-to-XML, you can now do some of the things provided by XPath in a way you already know how to do them... A few years ago, I wrote a Blackjack game. The game uses statistics from a book on expert play and coaches the player in the statistically best play based on the player's and dealer's hands. The game and source is available from my website... The game was good enough that a programmer from Harrah's in Biloxi asked to use the source, and my understanding is that it is a pillow favor provided at the casino. In this article, game statistics from a round of play were saved as an XML file and that file is used for the demos. You can download the game and save your own statistics or use the XML provided... The first example shows the basic flow—you are shown some code that uses LINQ-to-XML to query nodes followed by an equivalent XPath query that accomplishes the same goal... The XML in Listing Two shows the proper placement of the namespace jack added to the XML from Listing One. The code in Listing Three incorporates the namespace in the LINQ-to-XML to obtain the net amount won (or lost) from the XML file in Listing One. The second half of the listing uses the XPathSelectElement method and an XPath query to obtain the same value... Another thing you might want to do is find the value of child elements. To trim up the code for this example, you can use the XML in Listing One without the namespace. The LINQ-to-XML uses imperative code and the XElement object chained together to request children, and the XPath query uses a value that looks a lot like a file path statement... Transforming XML Data Using Functional Construction Functional construction is quite literally a way to create an XML tree in a single statement by chaining function calls together where subordinate calls are arguments to the calling method. This same nesting of method calls is also often used in the CodeDOM namespace to create code graphs. The XML document in Listing One was created with functional construction. Quite straightforward really, the XML tree was created by chaining XElement (and XAttribute) objects together to form the shape of the XML document and calling the XElement.Save method...

Create a Maintainable Extensible XML Format
Adriaan de Jonge and S. E Slack, IBM developerWorks

Over the past 10 years, XML has become a common, well-accepted standard for storing and exchanging data within and between organizations. Because XML itself is only an abstraction, the success of the format completely depends on the XML format designed by the organization or by a group of organizations. Just like any software product, these XML formats face maintenance challenges as business requirements change. And it's not just the need for changes in general: XML formats must often be updated for multiple organizations at the same time for competitive and market reasons. Maintaining just one XML schema is relatively simple. Making a change that affects several hundred organizations, however, can have an immense impact. You can use up plenty of time and money just to address a simple XML schema change that, designed correctly up front, causes little more than a extra glance at the information. This article discusses two things: (1) How to manage this impact; (2) How to minimize this impact where possible. We use some very simplistic examples containing cars, tires, and windscreens and their related companies or resellers. Although not completely realistic, this is sufficient to describe suggestions to improve the maintainability of XML formats... You don't want to treat XML schemas as automatically generated technicalities if you want to keep your XML formats maintainable in large enterprises and their surroundings. You can choose from many more ways to improve the maintainability of XML schemas. You can even describe your XML format in other languages, like Schematron and RELAX NG. Whatever you use, design the right XML format up front, and you can meet the needs of everyone involved in the communication.

Versions in the Universal Business Language (UBL)
G. Ken Holman, Balisage 2008 Presentation

There are many aspects of "different versions" when considering the artefacts defined for the OASIS Universal Business Language (UBL). UBL is expected to be widely deployed over a long period of time. How it is specified needs to support deployments in a heterogeneous network of different levels of implementation in different scenarios with different participants. Differences in versions can be seen in three different perspectives of the one specification. This paper describes: (1) different versions of the UBL standard defined by the UBL technical committee, (2) different versions of UBL customizations defined by communities of users, and (3) different versions of deployed code lists defined by trading partners using UBL. Some aspects described apply only to UBL because of characteristics of UBL not shared with other vocabularies. This may limit how other vocabularies can take advantage of the approaches being used... A user community can create a conformant customized subset and/or extended version of the UBL schemas by removing optional standardized constructs and by adding non-standardized constructs only underneath the document's extension point. A individual in that community can choose from different versions of value constraints to layer on top of the community's structural and lexical constraints based on arbitrary trading partner requirements. These versions are expressed as code and identifier lists combined with business rules placed on the values. This illustrates how a single XML vocabulary can be deployed into a heterogeneous network of differing implementation levels and different business contexts, while still promoting interoperability and standardized committee structures. The proposed processing model supports applications relying on schema-validity for instance inspection. Using this model, any individual will be able to access an instance from any other individual in any UBL community. Combining the document constraints with the out-of-band business constraints any two parties can successfully interchange information without schema validity being a barrier to access.


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

Headlines

Sponsors