This issue of XML Daily Newslink is sponsored by:
IBM Corporation http://www.ibm.com
Do We Need a New Kind of Schema Language?
James Clark, James Clark's Random Thoughts
I see the real pain-point for distributed computing at the moment as not the messaging framework but the handling of the payload. A successful distributed computing platform needs (1) a payload format, (2) a way to express a contract that a payload must meet, and (3) a way to process a payload that may conform to one or more contracts... that is suitable for average, relatively low-skill programmers, and allows for loose coupling (version evolution, extensibility, suitability for a wide variety of implementation technologies). For the payload format, XML has to be the mainstay, not because it's technically wonderful, but because of the extraordinary breadth of adoption that it has succeeded in achieving. We also have to live in a world where XSD is currently dominant as the wire-format for the contract (thank you, W3C, Microsoft and IBM). But I think it's fairly obvious that current XML/XSD databinding technologies have major weaknesses when considered as a solution to problem of payload processing for a distributed computing platform. The [XML/XSD databinding] pain is experienced most sharply at the moment in the SOAP world, because the big commercial players have made a serious investment in trying to produce tools that work for the average developer. But I believe the REST world has basically the same problem: it's not really feeling the pain at the moment because REST solutions are mostly created by relatively elite developers who are comfortable dealing with XML directly. The REST world also takes a less XML-centric view of the world, but for non-XML payload formats (JSON, or property-value pairs) its only solution to the contract problem is a MIME type, which I think is totally insufficient as a contract mechanism for enterprise-quality distributed computing... There seems to me to be another approach for improving things in this area, which I haven't seen being proposed... The basic idea is to have a schema language that operates at a different semantic level. In the following description I'll call this language TEDI (Type Expressions for Data Interchange, pronounced "Teddy"). This idea is very much at the half-baked stage at the moment. I don't claim to have fully thought it through yet. TEDI would be defined in terms of a generic data model that makes a tasteful restricted choice from these programming languages' data structures: not limiting the choice to the lowest common denominator, but leaving our frills and focusing on the basics and on things that be naturally mapped into each language. At least initially, I think I would restrict TEDI to trees rather than handle general graphs. Although graphs are important, I think the success of JSON shows that trees are good enough as a programmer-friendly data interchange mechanism. I would envisage both an XML and a non-XML syntax for TEDI..."
See also: on James Clark
W3C Voice Browser Patent Advisory Group Recommends that CCXML Advance
Staff, W3C Announcement
In a Report of the 3rd Voice Browser PAG 2006 on CCXML, the W3C Patent Advisory Group (PAG) for the Voice Browser Working Group has concluded in a public report that the Working Group should continue to advance the CCXML specification along the W3C Recommendation Track. The conclusion follows an assertion from Nortel that the company does not believe that US patent number 6,701,366 includes any essential claims, as defined of the W3C Patent Policy. Nortel excluded the claims of that patent from its Royalty-Free licensing commitment when it joined the Voice Browser Working Group in June 2005. W3C appreciates communications from Nortel that helped the PAG reach their conclusion. CCXML, the language on call control, is developed by the Voice Browser WG within W3C. CCXML is currently in Last Call. CCXML is designed to provide telephony call control support for dialog systems, such as VoiceXML. While CCXML can be used with any dialog systems capable of handling media, CCXML has been designed to complement and integrate with a VoiceXML interpreter. Because of this there are many references to VoiceXML's capabilities and limitations. There are also details on how VoiceXML and CCXML can be integrated. However, it should be noted that the two languages are separate and are not required in an implementation of either language. For example, CCXML could be integrated with a more traditional Interactive Voice Response (IVR) system or a 3GPP Media Resource Function (MRF), and VoiceXML or other dialog systems could be integrated with other call control systems.
See also: the W3C news item
Proposed WSFED Technical Committee: Divergence Point for Federation?
Gerry Gebel, Burton Group Blog
The March 20  announcement proposing a charter for a new OASIS Technical Committee for WS-Federation is rekindling a fire that has been smoldering for some time. Many a debate occurred at Catalyst and in other forums as to the merits of the WS-* long-term vision for web services security vs. SAML's immediate focus on browser-based federation scenarios. A common theme to these debates was a call for convergence of SAML, Liberty Alliance, and WS-Federation efforts. Meanwhile, vendors staked out positions regarding SAML, WS-Federation, and Liberty Alliance. Microsoft has held its ground in withholding support for the SAML protocol. IBM straddled the fence after initial reluctance to support Liberty ID-FF, ultimately supporting standards and specifications as demanded by customers. Most other vendors in the federation space hedged their bets by grudgingly supporting multiple protocols and specifications... Nearly two years ago, Burton Group published a report titled 'SAML 2.0: Convergence Point for Browser-Based Federation.' It contained the following statements, 'Security Assertion Markup Language (SAML) 2.0 represents a watershed moment for federation standards because it combines the efforts and features of SAML 1.x, Liberty Alliance Identity Federation Framework (IDFF), and Shibboleth' and 'OASIS may also attempt to foster more convergence for browser-based federation by working with the supporters of WS-Federation passive profile (WF-PP).' Obviously, this is not the case. Several have commented on the TC proposal, including Nokia, France Telecom, NTT, Sun, Oracle, and Neustar. In addition, Tim Bray posted a rip on his blog. The WSFED charter gives lip service to working on convergence with SAML 2.0. Like other commenters, we find this less than convincing; the WSFED charter's invitation to other standards committees looks like a passive-aggressive maneuver. It puts the onus on SAML 2.0, which has already been standardized, to come to WSFED on their terms and make changes to an established standard to accommodate features of a specification which was not developed in an open forum and is not yet a standard...
See also: Eve Maler
GRDDL Use Cases: Scenarios of Extracting RDF Data from XML Documents
Fabien Gandon (ed), W3C Technical Report
The W3C GRDDL Working Group has published "GRDDL Use Cases: Scenarios of Extracting RDF Data from XML Documents" as a Working Group Note, updating the document of 2006-10-02. With important applications such as connecting microformats to the Semantic Web, Gleaning Resource Descriptions from Dialects of Languages (GRDDL) is a mechanism to extract RDF statements from suitable XHTML and XML content using programs such XSLT transformations. The document collects a number of motivating use cases together with their goals and requirements for extracting RDF data from XML documents. These use cases also illustrate how XML and XHTML documents can be decorated with microformats, Embedded RDF or RDFa statements to support GRDDL transformations in charge of extracting valuable data that can then be used to automate a variety of tasks. The companion GRDDL Working Draft is a concise technical specification of the GRDDL mechanism and its XML syntax. It specifies the GRDDL syntax to use in valid XHTML and well-formed XML documents, as well as how to encode GRDDL into namespaces and HTML profiles. The companion document, the GRDDL Primer Working Draft, is a progressive tutorial on the GRDDL mechanism with illustrated examples taken from the GRDDL Use Cases Working Draft.
Google Delivers Maps Mashup Tool for Non-Techies
Juan Carlos Perez, InfoWorld
Google has created a tool to let non-technical users create Google Maps mashups, extending this capability beyond the realm of software developers. The feature, called My Maps, is designed to let users who don't have formal programming knowledge to create, annotate and publish online maps on the Google Maps platform. My Maps aims to provide to non-technical users some of the mashup capabilities that have been available for several years to developers via application programming interfaces (APIs), which require programming knowledge to use. Developers have created over 35,000 Google Maps mashups, marrying the Google mapping platform with external data sources to create all sorts of interactive maps where users can find information on apartments for rent, bike routes, hotels, gas station fuel prices, parking garage fares, and so on. My Maps has a graphical, drag-and-drop interface that lets users create a map, add placemarks to it, as well as draw lines and shapes. Users can also add notes, photos, audio clips, and videos to placemarks. In addition to My Maps, Google is also adding millions of KML files to its Maps search engine, another move to increase the volume of third-party data available for the mapping and local search service. KML (an XML-based markup language) stands for Keyhole Markup Language and it's the language used to create data files for both Google Maps and its sister desktop application Google Earth. In February 2007, Google made available these KML files via Earth's search engine and it's now including them in Google Maps as well. KML overlays have been created by casual users as well as by large organizations like Discovery Networks, the U.S. National Park Service, the Smithsonian Institution. and National Geographic.
See also: XML-based KML
Selected from the Cover Pages, by Robin Cover
The Web Services Interoperability Organization (WS-I) has announced the release of the Basic Security Profile Version 1.0 as Final Material. The Profile consists of a set of non-proprietary Web services specifications, along with clarifications to and amplifications of those specifications which promote interoperability. Publication of BSP 1.0 has been praised by Web Services security experts as a key enabling technology to enhance interoperability and improve security. The Basic Security Profile Version 1.0 was produced by members of the WS-I Basic Security Profile Working Group, chaire by Paul Cotton. The Basic Security Profile Working Group was chartered to develop an interoperability profile dealing with transport security, SOAP messaging security and other Basic-Profile-oriented Web services security considerations. The WS-I Basic Security Profile "is an interoperability profile that addresses transport security, SOAP messaging security, and other security considerations for WS-I's Basic Profile 1.1, Simple SOAP Binding Profile 1.0, and Attachments Profile 1.0. Specifically, the BSP 1.0 document focuses on the interoperability characteristics of two technologies: HTTP over TLS and Web Services Security: SOAP Message Security. HTTP over TLS is a point-to-point technology that protects the confidentiality of all information that flows over an HTTP connection. Web Services Security: SOAP Message Security provides security protection for SOAP messages and applies even when a message passes through several intermediary waypoints, allowing differing levels of protection for selected portions of a message. The BSP 1.0 specification describes a way to apply SOAP Message Security to attachments. The BSP 1.0 also incorporates WSS token profiles.
XML Daily Newslink and Cover Pages are sponsored by:
|BEA Systems, Inc.||http://www.bea.com|
|Sun Microsystems, Inc.||http://sun.com|
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/