Robin Cover

XML Daily Newslink
Subject: XML Daily Newslink. Thursday, 29 May 2008

XML Daily Newslink. Thursday, 29 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
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.

nla_internal_3021372.jpg also Atom references: http://xml.coverpages.org/atoml.html

----------------------------------------------------------------------

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.

http://www.25hoursaday.com/weblog/2008/05/28/NotTurtlesAtomPubAllTheWayDown.aspx
See also Anil's blog: http://www.dashes.com/anil/2008/04/atom-wins-the-unfied-cloud-database-api.html

----------------------------------------------------------------------

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.

http://www.oreillynet.com/xml/blog/2008/05/validating_ant_with_schematron.html
See also Schematron references: http://xml.coverpages.org/schematron.html

----------------------------------------------------------------------

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.

http://xml.coverpages.org/WS-I-Gartner-200806.html
See also WS-I specifications: http://www.ws-i.org/deliverables/index.aspx

----------------------------------------------------------------------

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.

http://lists.oasis-open.org/archives/tc-announce/200805/msg00005.html

----------------------------------------------------------------------

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.

http://www.w3.org/TR/2008/WD-xhtml-access-20080526/

----------------------------------------------------------------------

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.

http://xml.coverpages.org/draft-ietf-vcarddav-carddav-00.txt
See also the IETF vCard and CardDAV (VCARDDAV) Working Group: http://www.ietf.org/html.charters/vcarddav-charter.html

----------------------------------------------------------------------

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.

http://xml.coverpages.org/draft-ietf-idnabis-bidi-00.txt
See also the IETF Internationalized Domain Names in Applications (Revised) (IDNABIS) Working Group: http://www.ietf.org/html.charters/idnabis-charter.html

----------------------------------------------------------------------

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.

http://www.ibm.com/developerworks/web/library/wa-aj-sectools.html

----------------------------------------------------------------------

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.

http://www.ibm.com/developerworks/library/x-xformsruby2/
See also article part 1: http://www.ibm.com/developerworks/xml/library/x-xformsruby1/

----------------------------------------------------------------------

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/

----------------------------------------------------------------------

Back to newsletter list

Date:

From:

Subject:

XML Daily Newslink. Thursday, 29 May 2008