Cover Pages: XML Daily Newslink: Tuesday, 14 December 2010

Newsletter Archive: http://xml.coverpages.org/newsletterArchive.html
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:
ISIS Papyrus http://www.isis-papyrus.com

Headlines

Possible Directions for the Future of XML: MicroXML
IETF Last Call for vCard XML Representation and vCard Format Specification
W3C Issues Best Practices to Create Smarter Mobile Web Applications
IETF Update: SAML 2.0 Bearer Assertion Grant Type Profile for OAuth 2.0
Apache Software Foundation Launches 'Apache Extras' Web Site
Making Sense of SOA

Possible Directions for the Future of XML: MicroXML
James Clark, Random Thoughts Blog

"There's been a lot of discussion on the xml-dev mailing list recently about the future of XML. I see a number of different possible directions. I'll give each of these possible directions a simple name: (1) XML 2.0: by this I mean something that is intended to replace XML 1.0, but has a high degree of backward compatibility with XML 1.0; (2) XML.next: by this I mean something that is intended to be a more functional replacement for XML, but is not designed to be compatible—however, it would be rich enough that there would presumably be a way to translate JSON or XML into it; (3) MicroXML: by this I mean a subset of XML 1.0 that is not intended to replace XML 1.0, but is intended for contexts where XML 1.0 is, or is perceived as, too heavyweight.

I am not optimistic about XML 2.0. There is a lot of inertia behind XML, and anything that is perceived as changing XML is going to meet with heavy resistance. Furthermore, backwards compatibility with XML 1.0 and XML Namespaces would limit the potential for producing a clean, understandable language with really substantial improvements over XML 1.0. XML.next is a big project, because it needs to tackle not just XML but the whole XML stack. It is not something that can be designed by a committee from nothing; there would need to be one or more solid implementations that could serve as a basis for standardization. Also, given the lack of compatibility, the design will have to be really compelling to get traction. I have a lot of thoughts about this, but I will leave them for another post.

In this post, I want to focus on MicroXML. One obvious objection is that there is no point in doing a subset now, because of the costs of XML complexity have already been paid. I have a number of responses to this. First, XML complexity continues to have a cost even when XML parsers and other tools have been written; it is an ongoing cost to users of XML and developers of XML applications. Second, the main appeal of MicroXML should be to those who are not using XML, because they find XML overly complex. Third, many specifications that support XML are in fact already using their own ad-hoc subsets of XML (eg XMPP, SOAP, E4X, Scala). Fourth, this argument applied to SGML would imply that XML was pointless.

HTML5 is another major factor. HTML5 defines an XML syntax (ie XHTML) as well as an HTML syntax. However, there are a variety of practical reasons why XHTML, by which I mean XHTML served as application/xml+xhtml, isn't common on the Web... So one of the major design goals I have for MicroXML is to facilitate polyglot documents. More precisely the goal is that a document can be guaranteed to be a valid polyglot document if: [i] it is well-formed MicroXML, and [ii] it satisfies constraints that are expressed purely in terms of the MicroXML data model. Now let's look in detail at what MicroXML might consist of [...]"

IETF Last Call for vCard XML Representation and vCard Format Specification
Simon Perreault and Peter W. Resnick (eds), IETF Internet Drafts

Marc Blanchet, Co-Chair of the IETF vCard and CardDAV (VCARDDAV) Working Group, announced a Working Group Last Call (WGLC) review for two "core" vCard specifications: vCard XML Representation and vCard Format Specification. The WGLC deadline is December 31 2010, after which the WG expects to develop extension specifications.

The IETF vCard and CardDAV (VCARDDAV) Working Group was chartered to produce a revision of the vCard specification (RFC 2426) at proposed standard status, along with an address book access protocol leveraging the vCard data format. "A personal address book (PAB) contains a read/write copy of attributes describing a user's interpersonal contacts. This is distinct from a directory which contains a primarily read-only copy of users within an organization. While these two data objects share a large number of common attributes, their use and access patterns are fundamentally different. The IETF has a standards-track data format (vCard) which has been successfully used to interchange both personal-address-book and user directory entry data objects. However, due to the lack of a standard access control model for LDAP, the lack of a standard LDAP schema and DIT-model for vCard PAB objects, and the different access patterns for PAB data (as opposed to directory data), the use of LDAP as an access protocol for PABs has had mixed results in practice. Moreover, the vCard format has been extended by many parties and the current specification is ambiguous for some objects....

The new 'vCard Format Specification' "defines the vCard data format for representing and exchanging a variety of information about individuals and other entities (e.g., formatted and structured name and delivery addresses, email address, multiple telephone numbers, photograph, logo, audio clips, etc.). Electronic address books have become ubiquitous. Their increased presence on portable, connected devices as well as the diversity of platforms exchanging contact data call for a standard... In this core specification, the text/vcard MIME content type contains contact information, typically pertaining to a single contact or group of contacts. The content consists of one or more lines; individual lines within vCard are delimited by the line break, which is a CRLF sequence (ASCII decimal 13, followed by ASCII decimal 10). Long logical lines of text can be split into a multiple-physical-line representation using the following folding technique. Content lines SHOULD be folded to a maximum width of 75 octets. Multi-octet characters MUST remain contiguous..."

The specification "vCard XML Representation" defines the XML schema of the vCard data format. "The underlying data structure for the XML representation is exactly the same as for the text-based vCard Format Specification, enabling a 1-to-1 mapping between the original vCard format and the XML representation. The XML formatting may be preferred in some contexts where an XML engine is readily available and may be reused instead of writing a stand-alone vCard parser. The XML schema is expressed in the RELAX NG language (compact) as presented in Appendix A of the specification. The general idea is to map vCard parameters, properties, and value types to XML elements. For example, the 'FN' property is mapped to the 'fn' element. That element in turn contains a text element whose content corresponds to the vCard property's value. vCard parameters are also mapped to XML elements. They are contained in the 'parameters' markup element, which is contained in property elements..."

W3C Issues Best Practices to Create Smarter Mobile Web Applications
Adam Connors and Bryan Sullivan (eds), W3C Recommendation

W3C has announced publication of a new standard "that will make it easier for developers and content providers to create dynamic mobile Web applications. The Mobile Web Application Best Practices, published as a W3C Recommendation, offers practical advice from many mobile Web stakeholders for the easy development and the deployment of mobile Web applications that work across many platforms...

Application designers value the ability to write code once and have it work in multiple environments. The rapid growth of the market for mobile applications has increased the appeal of using the Web as development platform on these devices as well; that point is made in a white paper from a GIA analyst. Web applications are already replacing native applications in many computers, and we expect a similar trend on mobile devices in the near future since the Web platform addresses the fragmentation issues so familiar to mobile developers. The Web also makes it fast and easy to deploy and update applications without requiring any intervention of the user, and enables seamless integration of cloud-based services. Users, too, recognize the value of Web-based applications

The Mobile Web Application Best Practices indicates how to design Web applications that are responsive to their usage context, while sparing the network and optimizing response time to significantly boost the overall mobile user experience. With the ongoing work in the HTML5, CSS3, SVG, and WAI-ARIA Working Groups, the Web is catching up quickly with the ability to build a superior user interface. This concerted work drives innovations and new usages that only the Web platform enables. W3C is creating an even more powerful platform for developers, including better hardware and sensors integration. The Web Applications, Web Notifications, Web Events, Device APIs and Policy, and Geolocation Working Groups are bringing a wealth of JavaScript APIs that will reduce the gap between Web and native applications...

The Recommendation thus "sets out a series of recommendations designed to facilitate development and delivery of Web applications on mobile devices. The recommendations are offered to creators, maintainers and operators of mobile Web sites. The approach in writing this document has been to collate and present the most relevant engineering practices prevalent in the development community today and identify those that: (a) facilitate the exploitation of device capabilities to enable a better user experience; or (b) are considered harmful and can have non-obvious detrimental effects on the overall quality of an application. Readers of this document are expected to be familiar with the creation of Web applications, and to have a general familiarity with the technologies involved, but are not expected to have a background in mobile technologies or previous experience with 'Mobile Web Best Practices (BP1)'

See also: the W3C press release [TOC]

IETF Update: SAML 2.0 Bearer Assertion Grant Type Profile for OAuth 2.0
Brian Campbell and Chuck Mortimore (eds), IETF Internet Draft

A revised IETF Internet Draft has been issued for the specification SAML 2.0 Bearer Assertion Grant Type Profile for OAuth 2.0, updating the initial publication of July 27, 2010. The OASIS Security Assertion Markup Language (SAML) 2.0 standard "is an XML-based framework that allows for identity and security information to be shared across security domains. The SAML specification, while primarily targeted at providing cross domain web browser single sign-on, was also designed to be modular and extensible to facilitate use in other contexts. The Assertion, an XML security token, is a fundamental construct of SAML that is often adopted for use in other protocols and specifications. An Assertion is generally issued by an identity provider and consumed by a service provider who relies on its content to identify the Assertion's subject for security related purposes.

OAuth 2.0 provides a method for making authenticated HTTP requests to a resource using an access token. Access tokens are issued to third-party clients by an authorization server (AS) with the (sometimes implicit) approval of the resource owner. OAuth defines multiple profiles for obtaining access tokens to support a wide range of client types and user experiences. One such method is one in which the client trades an 'assertion' (not specifically a SAML Assertion) for an access token using the so-called 'assertion grant_type'. However OAuth 2.0 leaves the specific format and validation of the assertion out of scope.

This specification profiles the use of a SAML 2.0 bearer Assertion in requesting an access token using the assertion grant_type from OAuth 2.0. The format and processing rules for the SAML Assertion defined in this specification are intentionally similar, though not identical, to those in the Web Browser SSO Profile defined in [the OASIS standard] 'Profiles for the OASIS Security Assertion Markup Language (SAML) V2.0', reusing, to the extent reasonable, concepts and patterns from that well-established profile.

This level -01 specification revision: updates examples; relaxes processing rules to allow for more than one 'SubjectConfirmation element'; removes the 'MUST NOT contain a NotBefore attribute' on 'SubjectConfirmationData'; relaxes wording that ties the subject of the Assertion to the resource owner; adds some wording about identifying the client when the subject hasn't directly authenticated including an informative reference to SAML V2.0 Condition for Delegation Restriction; adds a few examples to the language about verifying that the Assertion is valid in all other respects; adds wording to the introduction about the similarities to Web SSO in the format and processing rules; changes the grant_type (was assertion_type) URI; changed title to include 'Grant Type' in it; provides editorial updates based on feedback from the WG and others, including capitalization of Assertion when referring to SAML..."

See also: SAML references [TOC]

Apache Software Foundation Launches 'Apache Extras' Web Site
Staff, ASF Announcement

"The Apache Software Foundation (ASF) has announced 'apache-extras.org' as a Google-hosted site for code associated with Apache projects that are not part of the Foundation's more than eighty Top-level Projects and dozens of initiatives in the Apache Incubator and Labs. Examples: HTTP, Server, Abdera, ActiveMQ, Ant, APR, Archiva, Avro, Axis, Buildr, Camel, Cassandra, Cayenne, Click, Cocoon, Commons, Continuum, CouchDB, CXF, DB, Directory, Excalibur, Felix, Forrest, Geronimo, Gump, Hadoop, Harmony, HBase, HttpComponents, Jackrabbit, Jakarta, James, Karaf, Lenya, Logging, Lucene, Mahout, Maven, Mina, MyFaces, Nutch, ODE, OFBiz, OpenEJB, OpenJPA, OpenWebBeans, PDFBox, Perl, Pivot, POI, Portals, Qpid, Roller, Santuario, ServiceMix, Shindig, Shiro, Sling, SpamAssassin, STDCXX, Struts, Subversion, Synapse, Tapestry, TCL, Thrift, Tika, Tiles, Tomcat, TrafficServer, Turbine, Tuscany, UIMA, Velocity, Wicket, Web, Services, Xalan, Xerces, XML, XMLBeans, Graphics...

Among the ASF's strengths are its well-established requirements relating to intellectual property management, license use, and community management. Apache-extras.org provides a home for projects that are unable to, or do not wish to, conform to those rules yet still want to signal their relationship to official Apache projects. As projects on the new Google-hosted service will not be managed by The Apache Software Foundation, participants are allowed to use whatever license and project management process they desire. Apache-extras.org will provide a level of visibility for these projects that is unavailable on other code-hosting forges.

Existing Google Code projects related to Apache products can be easily migrated to the new apache-extras.org site, whilst those involved with new Apache-related projects can start quickly by filling out a simple form. The ASF Community Development team will work directly with Apache Extras to ensure innovation around Apache projects is accelerated... Apache Extras provides a home for Apache related software which is not formally a part of the ASF itself. Having these projects on a single hosting platform will help to further accelerate innovation involving Apache software.

Established in 1999, the all-volunteer Foundation oversees nearly one hundred fifty leading Open Source projects, including Apache HTTP Server, the world's most popular Web server software. Through the ASF's meritocratic process known as 'The Apache Way,' more than 300 individual Members and 2,500 Committers successfully collaborate to develop freely available enterprise-grade software, benefiting millions of users worldwide: thousands of software solutions are distributed under the Apache License; and the community actively participates in ASF mailing lists, mentoring initiatives, and ApacheCon, the Foundation's official user conference, trainings, and expo. The ASF is funded by individual donations and corporate sponsors including AMD, Basis Technology, Facebook, Google, IBM, HP, Matt Mullenweg, Microsoft, SpringSource/VMware, and Yahoo!.

Making Sense of SOA
Rutrell Yasin, Government Computer News

Service-oriented architecture, a concept that has had many definitions, might be getting easier to understand. SOA is a flexible set of design principles used during the phases of systems development and integration in computing. A deployed SOA-based architecture should provide a loosely integrated suite of services that can be used within multiple business domains.

The Open Group has released a technical standard to foster a common understanding of SOA concepts and terminology between business analysts and information technology practitioners within organizations. A lack of mutually agreed-upon SOA terms, definitions and concepts can create interoperability issues that inhibit end-to-end business activities within an organization, according to Chris Harding, the SOA Work Group's forum director. It can also hinder communications between developers of information technology, users and partner organizations, reducing the success rate for SOA deployments...

SOA has not always lived up to its promise. But it's now past the stage of vendor-driven SOA in which vendors pushed SOA integration technology that in many cases did not meet the needs of organizations, David Mayo, president of Everware-CBDI and co-chairman of the Federal SOA Community of Practice, told GCN in and interview earlier this year. To that end, some federal agencies are finding that an incremental implementation of SOA concepts is helping in the creation of new system interfaces and interconnection with other systems.

For example, the Federal Aviation Administration is making progress on a service-oriented architecture designed to enhance the sharing of air traffic management system information among authorized personnel. The System Wide Information Management program is being implemented as a service-oriented architecture in the National Airspace System, which will let the FAA create new system interfaces more quickly and more cheaply. SWIM capabilities will be implemented as multiple services over the next five years..."


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

Headlines

Sponsors