Back to newsletter list
XML Daily Newslink. Monday, 19 May 2008
A Cover Pages Publication http://xml.coverpages.org/
Provided by OASIS http://www.oasis-open.org
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.
http://www.informationweek.com/news/internet/browsers/showArticle.jhtml?articleID=207800771
See also What's New: http://www.mozilla.com/en-US/firefox/3.0rc1/releasenotes/#whatsnew
----------------------------------------------------------------------
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.
http://www.w3.org/TR/2008/WD-scxml-20080516/
See also the W3C Voice Browser Activity: http://www.w3.org/Voice/Activity.html
----------------------------------------------------------------------
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."
http://docs.oasis-open.org/uoml-x/v1.0/cd01/uoml-part1-v1.0-cd01.html
See also the announcement: http://lists.oasis-open.org/archives/tc-announce/200805/msg00010.html
----------------------------------------------------------------------
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.
http://xml.coverpages.org/draft-nzrs-srs-00.txt
See also the SourceForge Domain Name Registry System Project: http://sourceforge.net/projects/dnrs/
----------------------------------------------------------------------
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.
http://www.w3.org/2008/02/xmlsec-charter
See also the Working Group home page: http://www.w3.org/2008/xmlsec/
----------------------------------------------------------------------
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.
http://www.w3.org/2001/tag/doc/nsDocuments-2008-05-16/
See also the diff-marked review copy: http://www.w3.org/2001/tag/doc/nsDocuments-2008-05-16/diff-20071113.html
----------------------------------------------------------------------
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.
http://www.infoworld.com/article/08/05/12/20TC-google-app-engine_1.html
----------------------------------------------------------------------
XML Daily Newslink and Cover Pages are sponsored by:
BEA Systems, Inc. http://www.bea.com
IBM Corporation http://www.ibm.com
Primeton http://www.primeton.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: newsletter-subscribe@xml.coverpages.org
Newsletter ***: newsletter-***@xml.coverpages.org
Newsletter help: newsletter-help@xml.coverpages.org
Cover Pages: http://xml.coverpages.org/
----------------------------------------------------------------------
