Cover Pages: XML Daily Newslink: Thursday, 23 September 2010

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

W3C First Public Working Draft for RDFa API Specification
SAML Enhanced Client SASL and GSS-API Mechanisms
Will Business Adopt BPMN 2.0?
New IETF Internet Draft: Public Safety Answering Point (PSAP) Callbacks
Open Text Upgrades Enterprise Content Management
Internet Media Types and the Web
Improve Ajax Development with jQuery
IETF Creates New Internet Privacy Discussion List

W3C First Public Working Draft for RDFa API Specification
Manu Sporny, Benjamin Adrian, Mark Birbeck, Ivan Herman; W3C TR

Members of the W3C RDFa Working Group have released a First Public Working Draft for the specification RDFa API: An API for Extracting Structured Data from Web Documents. RDFa, as defined in RDFa Core 1.1: Syntax and Processing Rules for Embedding RDF Through Attributes, specifies the use of attributes "to express structured data in any markup language. The embedded data already available in the markup language (e.g., XHTML) is reused by the RDFa markup, so that publishers don't need to repeat significant data in the document content.

RDFa enables authors to publish structured information that is both human- and machine-readable. Concepts that have traditionally been difficult for machines to detect, like people, places, events, music, movies, and recipes, are now easily marked up in Web documents. While publishing this data is vital to the growth of Linked Data, using the information to improve the collective utility of the Web for humankind is the true goal.

To accomplish this goal, it must be simple for Web developers to extract and utilize structured information from a Web document. This RDFa API document details such a mechanism—an RDFa Application Programming Interface (RDFa API) that allows simple extraction and usage of structured information from a Web document... A document that contains RDFa effectively provides two data layers. The first layer is the information about the document itself, such as the relationship between the elements, the value of its attributes, the origin of the document, and so on, and this information is usually provided by the Document Object Model, or DOM. The second data layer comprises information provided by embedded metadata, such as company names, film titles, ratings, and so on, and this is usually provided by RDFa, Microformats, DC-HTML, GRDDL, or Microdata..."

The mission of the RDFa Working Group, part of the Semantic Web Activity is to "support the developing use of RDFa for embedding structured data in Web documents in general. The Working Group will publish W3C Recommendations to extend and enhance the currently published RDFa 1.0 documents, including an API. The Working Group will also support the HTML Working Group in its work on incorporating RDFa in HTML5 and XHTML5."

See also: the W3C RDFa Working Group

SAML Enhanced Client SASL and GSS-API Mechanisms
Scott Cantor and Simon Josefsson (eds), IETF Internet Draft

Members of the IETF Common Authentication Technology Next Generation (KITTEN) Working Group have published a first working draft for the Standards Track specification SAML Enhanced Client SASL and GSS-API Mechanisms. The Generic Security Services (GSS) API and Simple Authentication and Security Layer (SASL) provide various applications with a security framework for secure network communication. The mission of the IETF KITTEN Working Group is to develop extensions/improvements to the GSS-API, shepherd specific GSS-API security mechanisms, and provide guidance for any new SASL-related submissions.

"Security Assertion Markup Language (SAML) 2.0 is a generalized framework for the exchange of security-related information between asserting and relying parties. Simple Authentication and Security Layer (SASL) and the Generic Security Service Application Program Interface (GSS-API) are application frameworks to facilitate an extensible authentication model. This document specifies a SASL and GSS-API mechanism for SAML 2.0 that leverages the capabilities of a SAML-aware 'enhanced client' to address significant barriers to federated authentication in a manner that encourages reuse of existing SAML bindings and profiles designed for non-browser scenarios.

The mechanism specified in this document allows a SASL-enabled server to act as a SAML relying party, or service provider (SP), by advertising this mechanism as an option for SASL clients that support the use of SAML to communicate identity and attribute information. Clients supporting this mechanism are termed 'enhanced clients' in SAML terminology because they understand the federated authentication model and have specific knowledge of the IdP(s) associated with the user. This knowledge, and the ability to act on it, addresses a significant problem with browser-based SAML profiles known as the 'discovery', or 'where are you from?' (WAYF) problem. Obviating the need for the RP to interact with the client to determine the right IdP (and its network location) is both a user interface and security improvement...

This document requires enhancements to the RP and to the client (as the two SASL communication endpoints) but no changes to the SAML IdP are assumed apart from its support for the applicable SAML profile. To accomplish this, a SAML protocol exchange between the RP and the IdP, brokered by the client, is tunneled within SASL. There is no assumed communication between the RP and the IdP, but such communication may occur in conjunction with additional SAML-related profiles not in scope for this document..." [Note nearby: (1) IETF 'Common Authentication Technology Next Generation (KITTEN) Working Group', (2) A SASL Mechanism for OAuth, (3) A SASL and GSS-API Mechanism for OpenID, (4) A SASL Mechanism for SAML.]

See also: 'A SASL Mechanism for SAML'

Will Business Adopt BPMN 2.0?
Boris Lublinsky, InfoQueue

"Many publications have established that one of the main prerequisites for success of the Business Process Management (BPM) undertakings is close cooperation between business and IT. One of the ways to ensure such cooperation is the development of the Business Process Management Notation (BPMN) standard, which is supposed to be a process definition language shared between IT and business.

BPMN 2.0 has introduced a lot of constructs allowing to directly define process execution and as a result has been adopted by several vendors as a run-time language for BPM. But many analysts think that such an enhanced execution support makes the language too complex for business users...

Keth Swenson notes that most of the enhancements to the new version of BPMN are for developers, not for business people, turning it into a graphical programming language for processes. He questions whether vendors will move from BPMN 1.2 to 2.0 if their focus is on modeling rather than execution.

Yes, the majority of the new features in BPMN 2.0 is aimed to make it an executable language and, yes, the complete standard is fairly complex, but as Bruce Silver explains in his book, BPMN 2.0 can be used on three different levels—descriptive, analytical and executable. If we assume that businesses will start from level 1 comprising 10 main icons, that can't be too complex. But the advantages of a formalized standard language understood and interpreted the same way by both business and IT are huge..."

New IETF Internet Draft: Public Safety Answering Point (PSAP) Callbacks
Henning Schulzrinne, Hannes Tschofenig, Milan Patel (eds), IETF Internet Draft

Members of the IETF Emergency Context Resolution with Internet Technologies (ECRIT) Working Group have published an initial level -00 version of the Informational Internet Draft Public Safety Answering Point (PSAP) Callbacks. The IETF emergency services architecture addresses callbacks in a limited fashion and thereby covers a couple of scenarios. This document discusses some shortcomings and raises the question whether additional solution techniques are needed. Document Section 4 'Topics for Investigation' raises technical and policy questions about callbacks.

"Summoning police, the fire department or an ambulance in emergencies is one of the fundamental and most-valued functions of the telephone. As telephone functionality moves from circuit-switched telephony to Internet telephony, its users rightfully expect that this core functionality will continue to work at least as well as it has for the legacy technology. New devices and services are being made available that could be used to make a request for help, which are not traditional telephones, and users are increasingly expecting them to be used to place emergency calls.

Regulatory requirements demand that the emergency call itself provides enough information to allow the call-taker to initiate a call back to the emergency caller in case the call dropped or to interact with the emergency caller in case of further questions. Such a call, referred as PSAP callback subsequently in this document, may, however, be blocked or forwarded to an answering machine as SIP entities (SIP proxies as well as the SIP UA itself) cannot associate the potential importance of the call based on the SIP signaling.

After an emergency call is completed (either prematurely terminated by the emergency caller or normally by the call-taker) it is possible that the call-taker feels the need for further communication or for a clarification. For example, the call may have been dropped by accident without the call-taker having sufficient information about the current situation of a wounded person. A call-taker may trigger a callback towards the emergency caller using the contact information provided with the initial emergency call. This callback could, under certain circumstances, then be treated like any other call and as a consequence, it may get blocked by authorization policies or may get forwarded to an answering machine..."

Open Text Upgrades Enterprise Content Management
Alison Diana, InformationWeek

Open Text has released the latest version of its enterprise content management product, ECM Suite 2010, including expanded features designed to improve social collaboration and mobility, manage compliance, enable users to work faster and more productively, and increase return on investment.

ECM Suite 2010 adds functionality through linked integration points for more than 90 products and modules, Open Text said. As a result, customers can manage an array of content types, applications, languages, user needs, and business processes...

The solution incorporates social collaboration via built-in capabilities for discussions, wikis, and forums. The suite's Open Text Pulse lets users microblog, follow colleagues, share content, and find experts. Corporations can fully secure and manage these social media capabilities under compliance rules

Users can customize their experiences by hiding unnecessary menus, creating personalized filters, and using custom columns. Open Text added facetted browsing and enhanced the search experience. The suite also includes multilingual metadata and language interface switching and lets users localize the application language to their businesses using company-specific dictionaries..."

See also: the Open Text announcement

Internet Media Types and the Web
Larry Masinter (ed), IETF Internet Draft

The Internet Engineering Task Force (IETF) has published an initial working draft of the Informational document Internet Media Types and the Web. Initial dicussion of some issues has taken place within the W3C Technical Architecture Group (TAG) on a related discussion list. From the document Abstract: "This document describes some of the ways in which parts of the MIME system, originally designed for electronic mail, have been used in the web, and some of the ways in which those uses have resulted in difficulties. This informational document is intended as background and justification for a companion Best Current Practice which makes some changes to the registry of Internet Media Types and other specifications and practices, in order to facilitate Web application design and standardization.

The goal of the document is to prompt an evolution within W3C and IETF over the use of MIME (and in particular Internet Media Types) to fix some of the outstanding problems. This is an initial version review and update. The goal is to initially survey the current situation and then make a set of recommendation to the definition and use MIME components (and specifically, Internet Media Types and charset declarations) to facilitate their standardization across Web and Web-related technologies with other Internet applications.

MIME was invented originally for email, based on general principles of 'messaging', a foundational architecture framework. The role of MIME was to extend Internet email messaging from ASCII-only plain text, to include other character sets, images, rich documents, etc.) The basic architecture of complex content messaging is: (1) Message sent from A to B. (2) Message includes some data. Sender A includes standard 'headers' telling recipient B enough information that recipient B knows how sender A intends the message to be interpreted. (3) Recipient B gets the message, interprets the headers for the data and uses it as information on how to interpret the data... [But now] The 'Internet Media Type registry' (MIME type registry) is where someone can tell the world what a particular label means, as far as the sender's intent of how recipients should process a message of that type, and the description of a recipients capability and ability for senders... The differences between the use of Internet Media Types between email and HTTP were minor (default charset; requirement for CRLF in plain text) but these minor differences have caused a lot of trouble...

Additional considerations treated in the presentation: There are related problems with charsets; Embedded, downloaded, launch independent application; Additional Use Cases: Polyglot and Multiview; Evolution, Versioning, Forking; Content Negotiation; Fragment identifiers..."

See also: MIME and the Web directions

Improve Ajax Development with jQuery
Kris Hadlock, IBM developerWorks

This article shows how to apply basic Asynchronous JavaScript + XML (Ajax) techniques in jQuery, such as making a request; handling success and error responses; and parsing the results from JavaScript Object Notation (JSON), XML, HTML, and dynamic PHP data sets.

It's no surprise that Ajax is a great way to enhance a web application. However, sometimes the code you need to write can take more time than traditional development techniques, especially when you're interacting with dynamic server-side data sets. Luckily, with the introduction of jQuery, there's now a quicker and more robust way to write JavaScript and Ajax code. The suite of Ajax functions available through jQuery makes Ajax development much easier than in the past by letting you write less code and by lending additional methods and event handlers to cover most situations.

The amount of code you need to write with jQuery is minimal, even when developing complex functions, so development is a lot faster. With these tools, Ajax is becoming a more viable option when developing a website or application... jQuery is essentially a JavaScript library that makes JavaScript development easier. It minimizes the code you need to write through its many built-in features—features for which you would typically need to write custom functions or objects.

This presentation demonstrates that the jQuery library improves Ajax development by making it much easier, requiring less code and providing additional control. These enhancements provide the foundation for rapidly building complex Ajax-enabled applications without writing a lot of code or needing broader deadlines. This article's samples alone prove how quick and easy it is build complex Ajax interactions in no time at all using jQuery—even when using multiple programming languages..."

See also: the jQuery web site

IETF Creates New Internet Privacy Discussion List
Staff, IETF Secretariat Announcement

IETF announced the creation of a new Internet Privacy Discussion List as a non-working group email list. The list is publicly subscribable, and is supported by list archives.

"This mailing list has been set up to discuss issues related to privacy that cut across multiple groups and areas. The initial goal of this discussion is to investigate privacy and related identity management terminology.

A secondary goal is to explore the opportunity to develop a Privacy Consideration guidelines document similar to the IETF Guidelines for Writing RFC Text on Security Considerations (IETF RFC 3552) used in the security area. The anticipation is that input into this list will come from solicited conversation within multiple other lists." [The IETF Geographic Location/Privacy (GEOPRIV) WG for example, is chartered to develop and refine representations of location in Internet protocols, and to analyze the authorization, integrity, and privacy requirements."

IETF Guidelines for Writing RFC Text on Security Considerations is published as a Best Current Practice document. "All RFCs are required to have a Security Considerations section. Historically, such sections have been relatively weak. This document provides guidelines to RFC authors on how to write a good Security Considerations section..."


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

Headlines

Sponsors