Cover Pages: XML Daily Newslink: Thursday, 29 May 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:
BEA Systems, Inc. http://www.bea.com

Headlines

Atom Link Relation: Discuss
Not Turtles, AtomPub All the Way Down
Validating Ant with Schematron
WS-I Presents Specifications at Gartner Summit
Semantic Support for Electronic Business Document Interoperability TC
W3C Last Call Review: XHTML Access Module
vCard Extensions to WebDAV (CardDAV)
An Updated IDNA Criterion for Right-to-Left Scripts
Ajax Security Tools
XForms and Ruby on Rails at the Doctor's Office, Part 2

Atom Link Relation: Discuss
Peter Saint-Andre (ed), IETF Internet Draft

The "Atom Syndication Format" defined in IETF RFC 4287 is an XML-based document format that describes lists of related information known as "feeds". Feeds are composed of a number of items, known as "entries", each with an extensible set of attached metadata. Such metadata can include links to other resources, which are primarily defined by Uniform Resource Indentifiers (URI) or Internationalized Resource Indentifiers (IRI). A link can be secondarily defined as partaking in a specific kind of relationship to the document. This "Atom Link Relation: Discuss" specification defines a new link relation, ("discuss") which can be used to point to Internet resources where a person can actively engage in a multi-party discussion or conversation about the document itself or the primary topic covered by the document. Any Atom link element with a 'rel' attribute value of "discuss" is used to reference an Internet resource where multi-party discussion of the feed, entry, or source can occur. In the terminology of this specification, such a resource is called a "venue". Such venues might include, but are not limited to, the following: Electronic mail discussion lists; Network news discussion boards (NNTP); Internet Relay Chat channels (IRC); Web-based forums accessible via the Hypertext Transport Protocol (HTTP); Multi-user chat rooms based on the Extensible Messaging and Presence Protocol (MUC and XMPP); Multi-user chat rooms based on the Message Session Relay Protocol (MSRP); Voice or video conference rooms based on the Session Initiation Protocol (SIP)... The use of the "discuss" relation enables a person who receives an Atom feed or entry to discover a venue where the person can engage in a conversation about the feed or entry with interested others. This use case is not currently addressed by any existing Atom link relation, which to date address use cases such as reading background material (the "related" relation) or following other people's comments (the "comments" relation) rather than actively engaging in a conversation or discussion about the feed or entry. It is expected that a link relation of type "discuss" would be presented to a human user in such a way that the user would understand that following the link would result in joining an active discussion venue rather than accessing a static resource. One example shows an Atom entry that contains numerous links related to the ejabberd XMPP server project, including links to an XMPP chatroom, an email discussion list, a web forum, and two web pages with background information.

See also: Atom references

Not Turtles, AtomPub All the Way Down
Dare Obasanjo, Blog

Last month Anil Dash commented on recent announcements about Microsoft's strategy around Web protocols (saying) "AtomPub has become the standard for accessing cloud-based data storage. From Google's GData implementation to Microsoft's unified storage platform that includes SQL Server, Atom is now a consistent interface to build applications that can talk to remote databases, regardless of who provides them. And this milestone has come to pass with almost no notice from the press that covers web APIs and technology..." I don't think the Atom publishing protocol can be considered the universal protocol for talking to remote databases given that cloud storage vendors like Amazon and database vendors like Oracle don't support it yet. That said, this is definitely a positive trend... Microsoft is using AtomPub as the interface to a wide breadth of services and products. [Microsoft's] FeedSync, one of the core parts of the Live Mesh platform, isn't really AtomPub but it does use the Atom syndication format so I count that as a win for Atom+APP as well. As time goes on, I hope we'll see even more products and services that support Atom and AtomPub from Microsoft. Standardization at the protocol layer means we can move innovation up the stack. We've seen this happen with HTTP and XML, now hopefully we'll see it happen with Atom + AtomPub. Finally, I think it's been especially cool that members of the AtomPub community are seeing positive participation from Microsoft, thanks to the folks on the Astoria team who are building ADO.NET Data Services (AtomPub interfaces for interacting with on-site and cloud based SQL Server databases). Kudos to Pablo, Mike Flasko, Andy Conrad and the rest of the Astoria crew.

See also: Anil's blog

Validating Ant with Schematron
Rick Jelliffe, O'Reilly Articles

Charles Goldfarb's idea of using grammars to represent documents has proven itself useful in many situations, and the DTD legacy lives on in ISO RELAX NG and W3C XSD. However, there are many structures that regular grammars, as conventionally implemented, cannot cope with. And it is possible to get a certain cart-before-the-horse mentality about grammars, where any structure that cannot be represented by a grammar is regarded as bad ipso facto. However, we need to be striving towards systems that free us so that what is congenial to the mind is easy to do on the computer. I was looking at Ant files recently and they provide another good example. Ant files are configuration files for a modern make system, open source through Apache and most associated with Java development. Ant files are mostly a defined set of elements and attributes which you could have a grammar-based schema for quite easily. But you can extend the elements inline in the document itself. For example, I am working on an Ant task for Schematron, to be available as an Ant extension—updating Christopher Lauret and Willy Ekasalim's work. [Looking at the sample Schematron XPath code:] The first rule finds every element that is a child of target for which there is an in-scope taskdef element for that name. In-scope means that any taskdef underneath any ancestor. The assertions in this rule can never fail, and they just filter out properly defined extension elements so that they do not fire the second rule. The second rule, which applies to any other element under target, checks against the full list of the built-in Ant tasks. That grammars cannot represent this is not just a lost opportunity for better validation: after all, the Ant program itself can generate messages. But it is a real shortfall for documentation: I cannot see one place in the Ant documentation in which all the structural rules are consolidated. I suppose if you are not used to going to a schema first, then you might not miss it, but I think one of the major convenience factors of DTDs, RELAX NG compact syntax, and Schematron can be the convenient and terse collection of structural rules, like a help card for programmers. So a quick comment to developers: if you have used XML for configuration files or other things, and then found that XSD doesn't have enough power to represent what you have, it is most likely that ISO Schematron can do the job, and do it with clearer diagnostics.

See also: Schematron references

WS-I Presents Specifications at Gartner Summit
Staff, WS-I Announcement

The Web Services Interoperability Organization announced that it is participating in the Standards Corner at Gartners Application Architecture, Development & Integration Summit 2008 in Orlando, FL from June 9-11, 2008 at the Orlando World Center Marriott Resort & Convention Center. WS-I representatives will be on hand to answer questions about the organization. WS-I is pleased to partner with Gartner for the twentieth edition of its Application Architecture, Development & Integration Summit, said Michael Bechauf, president and chairman of WS-I. Both WS-I and the Summit are focused on Best Practices, so attendees looking to derive maximum value from their services-oriented architecture will benefit from visiting us at the Standards Corner. This is the third ADDI Summit in which WS-I has participated. WS-I has a number of Profiles in progress. (1) Basic Profile: The WS-I Basic Profile 1.2 is a revision of the WS-I Basic Profile 1.1 and incorporates asynchronous messaging. It is based on the following Web Services specifications: W3C WS-Addressing 1.0 Core W3C WS-Addressing 1.0 SOAP Binding W3C WS-Addressing 1.0 WSDL Binding SOAP 1.1 Binding for MTOM 1.0 The Basic Profile 2.0 builds on the Basic Profile 1.2 and is based on SOAP 1.2 with Message Transmission Optimization Mechanism (MTOM) and XML-binary Optimized Packaging (XOP). (2) Basic Security Profile 1.1: The Basic Security Profile is an interoperability profile that addresses transport security, SOAP messaging security and other security considerations. It references existing specifications and standards, including the OASIS Web Services Security: SOAP Message Security 1.0 specification. The Basic Security Profile 1.1 is an enhancement to the Basic Security Profile 1.0 that provides guidance on the use of Web Services Security: SOAP Message Security 1.1, as well as the REL, Kerberos, SAML, Username and X.509 security token formats. (3) The Reliable Secure Profile (RSP) 1.0—will deliver interoperability guidance to Web Services architects and developers concerning reliable messaging with security. Reliable Secure Profile 1.0 will be based upon the following Web Services specifications: OASIS WS-ReliableMessaging 1.1 OASIS WS-SecureConversation 1.3 WS-ReliableMessaging is a Web Services specification that allows two systems to send messages to each other reliably. The aim of this specification is to ensure that messages are transferred properly from the sender to the receiver. The WS-SecureConversation specification introduces a security context and its usage. The Reliable Secure Profile 1.0 will resolve the interoperability issues that currently exist when these specifications are implemented.

See also: WS-I specifications

Semantic Support for Electronic Business Document Interoperability TC
Staff, OASIS Announcement

OASIS announced that members have submitted a draft charter to establish a new OASIS Semantic Support for Electronic Business Document Interoperability (SET) Technical Committee. A comment period for this proposal is open through 26-May-2008. UN/CEFACT Core Component Technical Specification (CCTS) is gaining widespread adoption by both the horizontal and the vertical standard groups. Universal Business Language (UBL) was the first implementation of the CCTS methodology. Some earlier horizontal standards such as Global Standard One (GS1) XML and Open Applications Group Integration Specification (OAGIS), and some vertical industry standards such as CIDX and RosettaNet have also taken up CCTS. The OASIS SET TC aims to specify semantic mechanisms to achieve interoperability among document standards based of UN/CEFACT CCTS used in B2B, B2G and G2G applications by continuing work initiated by the iSURF Project in three respects: (1) Semantic Support for Context Domains. The TC aims to specify semantic support mechanisms to provide machine processable semantic representations for the context domains to annotate core components to facilitate their discovery and reuse. This semantic will be obtained from the taxonomies and code lists already in use in the industry. This will allow the development of automated processes that intelligently search through custom components by interpreting class-subclass, equivalence and other relationships specified in context ontologies and gather applicable versions of components. (2) Semantic Support for Customization of Core Components and Business Document Schemas. The ability to automate schema customization will lead to a significant new flexibility, that is, it becomes possible to merge multiple versions of a component to generate additional versions of that particular component. This greatly simplifies the component customization effort as it is no longer necessary to manually provide customized components for every single business context. (3) Semantic Support for Document Translation. The OASIS SET TC will provide a machine processable mechanism that can express the structure and the semantics of components together with their correspondences in different versions. In this way, it will become possible to develop tools to help with semantic translation of Core component based electronic business documents. For this purpose, first a UBL "Component Ontology" will be developed.

W3C Last Call Review: XHTML Access Module
Mark Birbeck, Shane McCarron (et al., eds), W3C Technical Report

W3C's XHTML 2 Working Group has published the Last Call Working Draft for the specification "XHTML Access Module: Module to Enable Generic Document Accessibility." The Last Call Review ends 16-June-2008. The specification contains a single module designed to be used to help make XHTML-family markup languages more effective at supporting the needs of the Accessibility Community. It has been developed in conjunction with the W3C's Web Accessibility Initiative and other interested parties. It provides a generic mechanism for defining the relationship between document components and well-known accessibility vocabularies. XHTML Access is not a stand-alone document type. It is intended to be integrated into other XHTML Family Markup Languages. A conforming XHTML Access document is a document that requires only the facilities described as mandatory in this specification and the facilities described as mandatory in its host language. When XHTML Access is included in a host language, all of the facilities required in this specification must be included in the host language. In addition, the element defined in this specification must be included in the content model of the host language. The element defined in this specification may be incorporated into the namespace of the host language, or it may remain in the XHTML namespace. Finally, XHTML Access requires the availability of the XHTML Role Attribute Module and of the Core Attribute Collection as defined in XHTML Modularization... The "access" markup element assigns an accessibility mapping to elements within a document. Actuating the mapping results in the element gaining focus (either the document focus or an inspection focus, as determined by the user agent), and, if set by the author and permitted by the user's settings, in one or more other events being activated. An access element must have either a targetrole or a targetid attribute specified. If neither a targetrole nor a targetid attribute are specified, the user agent must not define a mapping nor deliver any events. The document appendices present an informative Schema Implementation and a normative DTD Implementation.

vCard Extensions to WebDAV (CardDAV)
Cyrus Daboo (ed), IETF Internet Draft

Members of the IETF vCard and CardDAV (VCARDDAV) Working Group have published an -00 version of the Internet Draft for "vCard Extensions to WebDAV (CardDAV)." This document defines extensions to the Web Distributed Authoring and Versioning (WebDAV) protocol to specify a standard way of accessing, managing, and sharing contact information based on the vCard format. Address books containing contact information are a key component of personal information management tools, such as email, calendaring and scheduling, and instant messaging clients. To date several protocols have been used for remote access to contact data, including Lightweight Directory Access Protocol LDAP (RFC 4511), Internet Message Support Protocol IMSP and Application Configuration Access Protocol ACAP (RFC 2244), together with SyncML used for synchronization of such data. WebDAV (RFC 4918) offers a number of advantages as a framework or basis for address book access and management. Most of these advantages boil down to a significant reduction in design costs, implementation costs, interoperability test costs and deployment costs. vCard (IETF RFC 2426, currently being updated) is a MIME directory profile aimed at encapsulating personal addressing and contact information about people. The specification of vCard was originally done by the Versit consortium, with a subsequent 3.0 version standardized by the IETF. vCard is in wide spread use in email clients and mobile devices as a means of encapsulating address information for transport via email, or for import/export and synchronization operations... a CardDAV address book is modeled as a WebDAV collection with a well defined structure; each of these address book collections contain a number of resources representing address objects as their direct child resources. Each resource representing an address object is called an "address object resource". Each address object resource and each address book collection can be individually locked and have individual WebDAV properties... A CardDAV server is an address-aware engine combined with a WebDAV server. The server may include address data in some parts of its URL namespace, and non-address data in other parts... XML Namespaces and Processing: Definitions of XML elements in this document use XML element type declarations (as found in XML Document Type Declarations). The namespace "urn:ietf:params:xml:ns:carddav" is reserved for the XML elements defined in this specification, its revisions, and related CardDAV specifications. XML elements defined by individual implementations must not use the "urn:ietf:params:xml:ns:carddav" namespace, and instead should use a namespace that they control... note that some CardDAV XML element names are identical to WebDAV XML element names, though their namespace differs. Care must be taken not to confuse the two sets of names. Processing of XML by CardDAV clients and servers must follow the rules described in Appendix A of RFC 4918.

An Updated IDNA Criterion for Right-to-Left Scripts
Harald Tveit Alvestrand and Cary Karp (eds), IETF Internet Draft

Members of the IETF Internationalized Domain Names in Applications [Revised] (IDNABIS) Working Group have issued a version -00 Internet Draft for "An Updated IDNA Criterion for Right-to-Left Scripts." The use of right-to-left scripts in internationalized domain names has presented several challenges. This memo discusses some problems with these scripts, and some shortcomings in the 2003 IDNA BIDI criterion. The Stringprep (RFC 3454) bidi algorithm states that "If a string contains any RandALCat character, a RandALCat character MUST be the first character of the string, and a RandALCat character MUST be the last character of the string." However, this makes certain words in languages written with right-to-left scripts invalid as IDN labels, and in at least one case means that all the words of an entire language are forbidden as IDN labels. This is illustrated below with examples taken from the Dhivehi and Yiddish languages, as written with the Thaana and Hebrew scripts, respectively. Based on this discussion, the draft proposes a new BIDI criterion for IDNA labels. When labels pass the test, they can be used with a minimal chance of these labels being displayed in a confusing way by a bidirectional display algorithm. In order to achieve this stability, it is also necessary that the test be applied to labels occuring before or after the label containing right-to-left characters, which prohibits some LDH-labels that are permitted in other contexts.

Ajax Security Tools
Judith Myerson, IBM developerWorks

Certain vulnerabilities within Ajax applications can allow malicious hackers to reek havoc with your applications. Identity theft, unprotected access to sensitive information, browser crashes, defacement of Web applications, and Denial of Service attacks are just a few of the potential disasters Ajax applications can be prone to and which developers need to guard against when building Ajax capabilities into their applications. Because security is critical to not only developers but also to testers, system administrators, and potential users, being aware of and resolving potential security issues before they happen can make your development team's and user's experiences trouble-free. In this article, you'll learn about Ajax security tools, which you'll be using to scan for SQL injection and cross-site scripting vulnerabilities; to set a master password; and to restore the state of all windows after crashes. You'll take a look at tools and utilities that ensure that linked Web sites in applications are not on the blocked lists and which prevent hackers from altering browser functionality, defacing Web applications, and achieving malicious results. You'll find these utilities divided into three types within the article: hardening tools, Firefox tools, and Firefox add-ons... Ajax Secure Service Layer (aSSL) is a tool to secure chats and blogs; HTMLProctector, is used to protect your Ajax Web pages from the visitors who want to steal your source code and images; Acunetix Web Vulnerability Scanner is used to scan for and fix problems caused by SQL injection and cross-site scripting.

XForms and Ruby on Rails at the Doctor's Office, Part 2
Michael Galpin, IBM developerWorks

This article is Part 2 in a four-part series about using XForms, IBM DB2 pureXML, and Ruby together to more easily create Web applications; the series develops a hypothetical application for managing patient information at a doctor's office. Article Part 1 discussed how the technologies allow you to use XML on the front and back ends of your application. One nice thing about this design is that it puts the XML data front-and-center. The design of your XML data model defines how you implement the XForms-based front end as well as how you retrieve data from DB2 using Ruby on Rails on the back end. So the logical place to start developing this application is to design the XML data model. The application will allow patients to enter information needed by the doctor and the staff in the office. You will need information such as the patient's name, insurance company, age, co-pay amount, and of course their symptoms. This article shows how to use XForms to create a data entry form for patients to enter their information. XForms takes care of binding patient data to an XML document and can even validate against an XML schema. The application submits this XML document to a Ruby on Rails controller. Ruby makes it easy to parse this input as XML and to serialize that XML as a string. DB2 understands the serialized XML string and can store it natively using pureXML technology. Rails is even able to display this data with no special work on your part. From here, you can use DB2 XML/SQL syntax to query the XML data or retrieve it and use Ruby to navigate and extract data. This article assumes familiarity with XML and with Web applications in general. It was written using the Mozilla XForms plugin version 0.8.0.3; this provides XForms runtime support in any Mozilla browser such as Firefox. Another very useful Mozilla plugin is XForms Buddy.

See also: article Part 1


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

Headlines

Sponsors