Cover Pages: XML Daily Newslink: Monday, 19 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:
Sun Microsystems, Inc. http://sun.com

Headlines

Firefox 3 Release Candidate 1 Now Available
State Chart XML (SCXML): State Machine Notation for Control Abstraction
UOML (Unstructured Operation Markup Language) Part 1 Version 1.0
System for Managing a Shared Domain Registry
W3C Charters XML Security Working Group
Associating Resources with Namespaces
First Look: Google's High-Flying Cloud for Python Code

Firefox 3 Release Candidate 1 Now Available
Thomas Claburn, InformationWeek

Mozilla Corporation has released Firefox 3 RC1, more or less the final form of this iteration of the popular open-source Web browser. RC stands for Release Candidate and represents a stage in which the browser's features are complete and the code is stable enough for public testing. Barring any serious bugs, RC1 will become the official release version of Firefox 3, which is planned for June 2008. Mozilla VP of engineering Mike Schroepfer claims that Firefox 3 is 9.3x faster than Microsoft Internet Explorer 7 and 2.7x faster than Firefox 2 in terms of JavaScript performance. In terms of Gmail message load time, he claims Firefox 3 is 6.8x faster than IE7 and 3.8x faster than Firefox 2. And he says Firefox 3 beats Apple's Safari, which is also faster than Firefox 2. Firefox 3 comes with more than 15,000 improvements, according Mozilla, but you have to be counting tiny changes very carefully to get to that number. More likely, you'll notice maybe two dozen new and improved features. The major new additions include the Smart Location Bar, One-Click Bookmarks, Tags, Library, Smart Bookmark Folder, the Gecko 1.9 Engine, Malware Protection, Instant Web Site ID, and Full Page Zoom. Features that aren't new but have nonetheless been reworked include the Add-On Manager, the Download Manager, Phishing Protection, the Password Manager, Security for Add-Ons, UI/OS Design Consistency, and Tabbed Browsing. The Smart Location Bar is the box that where Firefox users typically type URLs. In Firefox 3, it has become search-enabled, with respect to the user's search history. Typing a terms like "jeans" will return a drop-down list of Web sites related to that term. Another standout feature is Instant Web site ID, which provides a way to see Extended Validation SSL certificate information, when available, by clicking on a site's favicon—the little graphic that many Web sites display to the left of the browser location (URL) bar. Other security features deserve mention as well. The new malware and phishing protections built into Firefox 3 help prevent users from accessing sites blacklisted for hosting malware. The blacklist, which relies heavily on data provided by Google, is updated every 30 minutes.

See also: What's New

State Chart XML (SCXML): State Machine Notation for Control Abstraction
J. Barnett, R. Akolkar, R. Auburn (et al,, eds), W3C Technical Report

W3C announced that members of the Voice Browser Working Group have published a revised version of "State Chart XML (SCXML): State Machine Notation for Control Abstraction" as part of the W3C Voice Browser Activity. This fourth Public Working Draft updates the 2007-02-21 draft with (1) modularization of the language, (2) the introduction of profiles, and (3) a revision of the algorithm for document interpretation. Most sections have been modified because of above changes, so the the editors would like reviewers to read the whole document carefully and provide comments. SCXML (the "State Chart Extensible Markup Language") provides a generic state-machine based execution environment based on CCXML ["Voice Browser Call Control: CCXML Version 1.0"] and Harel State Tables. CCXML is an event-based state machine language designed to support call control features in Voice Applications—specifically including VoiceXML but not limited to it. The CCXML 1.0 specification defines both a state machine and event handing syntax and a standardized set of call control elements. Harel State Tables are a state machine notation that was developed by the mathematician David Harel and is included in UML. They offer a clean and well-thought out semantics for sophisticated constructs such as a parallel states. They have been defined as a graphical specification language, however, and hence do not have an XML representation. The goal of this document is to combine Harel semantics with an XML syntax that is a logical extension of CCXML's state and event notation. SCXML can be used in many ways, including: [1] As a high-level dialog language controlling VoiceXML 3.0's encapsulated speech modules; [2] As a voice application metalanguage; [3] As a multimodal control language in the MultiModal Interaction framework, combining VoiceXML 3.0 dialogs with dialogs in other modalities including keyboard and mouse, ink, vision, haptics, etc.; [4] As the state machine framework for a future version of CCXML; [5] As an extended call center management language combining CCXML call control functionality with computer-telephony integration for call centers; [6] As a general process control language in other contexts not involving speech processing.

UOML (Unstructured Operation Markup Language) Part 1 Version 1.0
Staff, OASIS Announcement

Members of the OASIS Unstructured Operation Markup Language Extended (UOML-X) Technical Committee have released an approved Committee Draft of the "UOML (Unstructured Operation Markup Language) Part 1 Version 1.0" specification for 60-day public review ending 15-July-2008. According to the document Overview: "UOML is interface standard to process unstructured document; it plays the similar role as SQL (Structured Query Language) to structured data. UOML is expressed with standard XML, featuring compatibility and openness UOML deals with layout-based document and its related information (such as metadata, rights, etc.) Layout-based document is two dimensional, static paging information, i.e. information can be recorded on traditional paper. The software which implements the UOML defined function, is called DCMS, applications can process the document by sending UOML instructions to DCMS. UOML first defines abstract document model, then operations to the model. Those operations include read/write, edit, display/print, query, security control; it covers the operations which required by all different kinds of application software to process documents. UOML is based on XML description, and is platform-independent, application-independent, programming language-independent, and vendor neutral. This standard will not restrict manufacturers to implement DCMS in their own specific way."

See also: the announcement

System for Managing a Shared Domain Registry
Matthew Hunt (ed), IETF Internet Draft

This document describes the typical usage and communication protocol of a client/server shared registry system for management of domain name registrations. The system described is a "thick registry" system, providing support for the storage and management of both the technical and the registrant contact information concerning domain registrations. The system relies on the existing HTTP and HTTPS infrastructure for transport and secure transfer to avoid having to implement a dedicated protocol and server environment. This document describes the Shared Registry System (SRS), a system for managing a shared domain name registry. This system broadly satisfies the requirements for a generic registry-registrar protocol as defined in RFC 3375. As this system only addresses the issue of managing a shared registry service and uses HTTP as its transport layer, implementations are expected to be relatively easy. This document also describes the communication protocol used by the SRS system. This protocol uses messages in an XML format for system requests and responses. The DTD for the SRS protocol is provided in its entirety as an appendix (Appendix C) to this document, and individual parts of the protocol are covered in depth throughout the document. The SRS works in a connection-oriented fashion with no session state. The registrar sends a request document to the registry containing commands to be executed by the SRS and the result of processing these commands is returned as the response. Each registrar request document receives a response document containing the result of processing all of the requests in a single request document. Public Key Infrastructure (PKI) is used to manage issues of security, authentication of requests and non-repudiation of actions. Exchange of keys between the registry and registrars is outside the scope of this document. A system built using this protocol is used by '.nz Registry Services (NZRS)' and a sample implementation consisting of client and server software is available from the Sourceforge web site.

W3C Charters XML Security Working Group
Staff, W3C Announcement

W3C announced the formation of the XML Security Working Group as part of the Security Activity, chartered through May 2010 to take the next step in developing the XML security specifications. Frederick Hirsch (Nokia) is the Working Group Chair, while Thomas Roessler serves as the W3C Security Activity Lead. The existing suite of XML security specifications has become a fundamental technology in the XML and Web Service worlds over the last seven years: The joint IETF/W3C XML Signature Working Group specified mechanisms to digitally sign XML documents and other data, and to encapsulate digital signatures in XML. The W3C XML Encryption Working Group specified mechanisms to encrypt XML documents and other data, and to encapsulate the encrypted material and related meta-information in XML. In 2007, the XML Security Specifications Maintenance Working Group took up limited maintenance work of the XML Signature Specification, and the XML Core Working Group prepared the Canonical XML 1.1 Recommendation, on which XML Signature depends. The W3C Workshop on Next Steps for XML Signature and XML Encryption identified next steps for this suite of technologies that are desirable to a broader community. The XML Security Working Group is chartered to evaluate and act on recommendations in the Workshop report in developing the XML Security specifications on the basis of lessons learned from implementation and deployment experience to date... Based on the requirements gathered in the first phase of its work, the Working Group will develop updates to the core XML Security specifications. The Working Group is asked to consider the benefits of compatibility with the existing specification environment. As part of its maintenance work, the XML Security Working Group may consider comments and updates to the following set of specifications: XML-Signature XPath Filter 2.0; Canonical XML Version 1.0; Canonical XML Version 1.1; Exclusive XML Canonicalization Version 1.0; Decryption Transform for XML Signature.

Associating Resources with Namespaces
Henry S. Thompson (ed), W3C Draft TAG Finding

Henry S. Thompson (W3C and HCRC Language Technology Group, University of Edinburgh) announced the publication of a revision to the W3C Draft TAG Finding "Associating Resources with Namespaces," updating the draft of 2007-11. The document addresses the question of how ancillary information (e.g., schemas, stylesheets, documentation, etc.) can be associated with a namespace. The names in a namespace form a collection: (1) Sometimes it is a collection of element names—DocBook and XHTML, for example; (2) sometimes it is a collection of attribute names—XLink, for example; (3) sometimes it is a collection of functions—XQuery 1.0 and XPath 2.0 Data Model; (4) sometimes it is a collection of properties -- e.g., FOAF; (5) sometimes it is a collection of concepts e.g., WordNet, and many other uses are likely to arise. There's no requirement that the names in a namespace only identify items of a single type; elements and attributes can both come from the same namespace as could functions and concepts or any other homogeneous or heterogeneous collection you can imagine. The names in a namespace can, in theory at least, be defined to identify any thing or any number of things. Given the wide variety of things that can be identified, it follows that an equally wide variety of ancillary resources may be relevant to a namespace. A namespace may have documentation (specifications, reference material, tutorials, etc., perhaps in several formats and several languages), schemas (in any of several forms), stylesheets, software libraries, applications, or any other kind of related resource. The names in a namespace likewise may have a range of information associated with them. A user encountering a namespace might want to find any or all of these related resources. In the absence of any other information, a logical place to look for these resources, or information about them, is at the location of the namespace URI itself. The details of exactly what this means may be subtlely different in different cases, but the general point is clear, as The Web Architecture says: "It is Good Practice for the owner of a namespace to make available at the namespace URI 'material intended for people to read and material optimized for software agents in order to meet the needs of those who will use the namespace'." ... RDDL 1.0 is an XLink-based vocabulary for connecting a namespace document to related resources and identifying their nature and purpose. RDDL 1.0 is now widely deployed. In addition, some of the proposed alternative formats are also deployed, and it seems likely that over time new variations may arise based on other evolving web standards. This finding therefore attempts to address the problem by considering it in a more general fashion. The document [1] Defines a conceptual model for identifying related resources that is simple enough to garner community consensus as a reasonable abstraction for the problem, [2] Shows how RDDL 1.0 is one possible concrete syntax for this model, and [3] Shows how other concrete syntaxes could be defined and identified in a way that would preserve the model.

See also: the diff-marked review copy

First Look: Google's High-Flying Cloud for Python Code
Peter Wayner, InfoWorld Review

"One of the joys of being a Web programmer is heading to a dinner party, a haircut, or a reunion and fielding the pitches for everyone's dream for a brilliant Web application. Everyone is always happy to cut you in for 5, 10, maybe even 15 percent of the equity if you just build out the Web site that's sort of like a combination of Twitter, AltaVista, Eliza, TurboTax, and the corner pharmacy, but cooler. Google App Engine is meant for dreams like these. You write a bit of code in Python, customize some HTML, and bingo, you've got your database-backed dynamic Web site up and running in a few short minutes. The magic comes when the world starts flocking to your Web application, and Google's cloud of computers quickly adapts to the load, handling everything the public demands. There's no need for you to buy servers, load balancers, or special DNS tables. Google's application cloud handles all of the grungy deployment headaches. I played around with the App Engine SDK and, sure enough, developed and deployed applications on my desktop with just a few minutes of work. I didn't upload them to the cloud because I didn't make it into the beta program, but I was able to simulate the experience on my office server. The billions of hits haven't shown up yet, but it has only been a few hours now. It works and it is quite simple... Google App Engine hides the grime of deploying a scalable application to a number of servers. The limitations on the sandbox make this "cloud" best for dynamic Web sites that act as a relatively thin layer of business logic sitting on top of a data store. Google's Python/Django framework makes developing simple applications quick, and the database structure encourages scalable design by excluding joins. On the downside, there's not much support for AJAX, porting some applications will require rethinking the database schema, and your coders better like Python, which is currently the only option. Applications are currently limited to daily quotas such as 2,000 e-mail messages, 200 million CPU megacycles, and 2.5 million data store calls. The documentation suggests that users will be able to spend money to expand the quotas.


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

Headlines

Sponsors