Robin Cover

XML Daily Newslink. Thursday, 17 April 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
Primeton http://www.primeton.com
====================================================

HEADLINES:

* Is HTML in a Race to the Bottom?
* Toward Integration: Demystifying RESTful Data Coupling
* BPEL Should Not Be the Serialization Standard
* Uncertainty Reasoning for the World Wide Web
* FAQs on ISO/IEC 29500
* Make SOA Transactional
* Requirements of Japanese Text Layout
* Google Data APIs Patent License
* Security for Services and Mashups

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

Is HTML in a Race to the Bottom? A Large-Scale Survey and Analysis of
Conformance to W3C Standards
Patricia Beatty, Scott Dick, James Miller; IEEE Internet Computing

In this article, researchers from the University of Alberta discuss an
analysis they've done on how the various versions of HTML and XHTML
are used, looking at exactly these problems. The World Wide Web
Consortium (W3C) promulgates the HTML standards used on the Web, but
it has no authority to enforce the adoption of one standard in favor
of another. In this environment, developers have some incentive to
ignore up-to-date W3C standards given that the transitional versions
of HTML 4.01 and XHTML 1.0 offer most of the capabilities of the newer
ones but are less stringent in their requirements. If most Web sites
migrate to these "transitional" standards and remain there, future
versions might be mere academic exercises for the W3C. The "race to
the bottom" is a familiar phenomenon that occurs when multiple standards
compete for acceptance. In this environment, the most lenient standard
usually attracts the greatest support (acceptance, usage, and so on),
leading to a competition among standards to be less stringent. This
also tends to drive competing standards toward the minimum possible
level of quality. One key prerequisite for a race to the bottom is
an unregulated market because regulators mandate a minimum acceptable
quality for standards and sanction those who don't comply. In
examining current HTML standards, we've come to suspect that a race
to the bottom could, in fact, be occurring because so many competing
versions of HTML exist... David Hammond, an advocate for standards-based
Web technologies, examined mainstream browsers' level of compliance
with common Web technologies, recommendations, and standards. With
respect to HTML and XHTML, he explored compliance in terms of
functionality for each and every language element within these
recommendations. [See the table for] browser support for HTML 4.01,
XHTML 1.0, and XHTML 1.1... Our survey findings imply that the current
effort to develop XHTML 2.0 might well be just an academic exercise.
The race to the bottom, however, isn't inevitable...

http://dsonline.computer.org/portal/pages/dsonline/2008/04/w2std.html

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

Toward Integration: Demystifying RESTful Data Coupling
Steve Vinoski, IEEE Internet Computing

Developers who favor technologies that promote interface specialization
typically raise two specific objections to the uniform-interface
constraint designed into the Representational State Transfer (REST)
architectural style. One is that different resources should each have
specific interfaces and methods that more accurately reflect their
precise functionality. The other objection to the concept of a uniform
interface is that it merely shifts all coupling issues and other
problems to the data exchanged between client and server. Yet, that's
based on the invalid assumption that the data exchanged in a REST system
is just like the data exchanged in systems such as Web services and
Corba, which require interface specialization... Compared to approaches
such as Web services and the Web Services Description Language (WSDL),
which promote specialization for each service interface, the
uniform-interface constraint reduces client-server coupling and helps
minimize gratuitous differences in interface and method semantics across
disparate resources. REST isn't a silver bullet, but its flexibility
and relative simplicity make it highly applicable not only to Web-scale
systems but also to a wide variety of enterprise integration problems...
Is REST's approach to dealing with data coupling some sort of magic? Of
course not. Although the REST constraints explored here can definitely
help reduce data coupling when compared to interface specialization
approaches, there are still issues to watch for. For instance, sending
representations typically means sending more data with each call than
in RPC-oriented systems. Even though RESTful systems are often simpler
and more efficient than their non-REST counterparts, this extra data
overhead can sometimes cause efficiency problems. Ultimately, reducing
interface and data coupling for your distributed applications isn't easy.

http://dsonline.computer.org/portal/pages/dsonline/2008/04/w2tow.html

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

BPEL Should Not Be the Serialization Standard
Jesper Joergensen, Blog

Bruce Silver has written another chapter (and follow-up) in the
developing story of BPMN and BPEL ("More on BPMN-to-BPEL"), which is
here taken up in Joergensen's blog "You can serialize BPMN into BPEL,
but BPEL should not be the serialization standard." -- BPMN is not
always easy to map to BPEL and the reason is that BPMN allows you to
draw a full graph while BPEL is block oriented, and Bruce's examples
illustrates it well. The pro-BPEL folks say that this is not a problem
because you can always devise a strategy to "unfold" the graph into
a block structure. That's true, you can always find a way to represent
a BPMN diagram in BPEL. But the way you choose to do this is likely
to be your way. It will not be standardized. Therefore, the same BPMN
diagram will end up looking different in BPEL depending on your
tool/engine/custom method. In theory, when the process executes, this
doesn't matter. The "unfolding" should not change the behavior specified
by BPMN, so the result of the execution should be the same if two
different strategies are chosen. But the problem is that the strategy
is proprietary. For example, A BPMN compliant BAM tool doesn't know
how to show process trace for a process executed in BPEL. A BPMN
compliant simulation tool cannot take the BPEL file and turn it back
into the original BPMN file because it doesn't know the strategy used
to go from BPMN to BPEL... It's pretty likely that no two applications
will invent the same BPMN meta model and thus the diagrams will look
and/or behave different even if it wasn't intended. This is the wrong
track. It is too error-prone, requires unnecessary duplication of work
(many meta models) and it forces too much focus on BPEL when BPEL is
really mostly relevant for execution. BPEL is not suitable for business
process modeling because it's too restrictive and machine oriented.
This has been acknowledged pretty widely in the industry, so I hope
it's not a controversial statement. This is not a criticism of BPEL
as an execution format. But it appears much more sensible to standardize
a meta model for BPMN and then let vendors build implementation specific
mappings to BPEL from there.

http://dev2dev.bea.com/blog/jesperfj/archive/2008/04/you_can_seriali.html
See also Bruce Silver's 'BPMN-to-BPEL': http://www.brsilver.com/wordpress/2008/04/04/more-on-bpmn-to-bpel/

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

Uncertainty Reasoning for the World Wide Web
Kenneth J. Laskey (et al., eds), W3C Incubator Group Report

W3C announced that the Uncertainty Reasoning for the World Wide Web
Incubator Group has published its final report. Uncertainty is an
intrinsic feature of many of the required tasks, and a full realization
of the World Wide Web as a source of processable data and services
demands formalisms capable of representing and reasoning under
uncertainty. Although it is possible to use semantic markup languages
such as OWL to represent qualitative and quantitative information
about uncertainty, there is no established foundation for doing so.
Therefore, each developer must come up with his/her own set of constructs
for representing uncertainty. This is a major liability in an environment
so dependent on interoperability among systems and applications. This
Report is the major deliverable of the URW3-XG and describes the work
done by the XG, identifies the elements of uncertainty that need to be
represented to support reasoning under uncertainty for the World Wide
Web, and includes a set of use cases illustrating conditions under
which uncertainty reasoning is important. Along with the use cases
(Section 5), this report also includes the Uncertainty Ontology
(Section 3) that was developed during the discussions within our work,
an overview of the applicability to the World Wide Web of numerous
uncertainty reasoning techniques and the information that needs to be
represented for effective uncertainty reasoning to be possible
(Section 4), and a discussion on the benefits of standardization of
uncertainty representation to the WWW and the Semantic Web (Section 6).
Finally, it includes a Reference List of work relevant to the challenge
of developing standardized representations for uncertainty and
exploiting them in Web-based services and applications.

http://www.w3.org/2005/Incubator/urw3/XGR-urw3-20080331/

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

FAQs on ISO/IEC 29500
Staff, International Organization for Standardization (ISO)

Excerpts: "Because the information technology (IT) sector is fast-moving,
the joint technical committee ISO/IEC JTC 1, Information technology,
introduced the "fast track" process for the adoption as ISO/IEC standards
of documents originating from the IT sector on which substantial
development has already taken place... Why would ISO and IEC allow
two standards for the same subject? The ICT industry has a long history
of developing multiple standards providing similar functionalities.
After a period of co-existence, it is basically the market that decides
which survives. A past example within ISO concerned the SGML (Standard
Generalized Markup Language) and ODA (Office Document Architecture). In
this particular case, some claim that the Open Document Format (ODF),
which is also an ISO/IEC standard (ISO/IEC 26300) and ISO/IEC 29500 are
competing solutions to the same problem, while others claim that ISO/IEC
29500 provides additional functionalities, particularly with regard to
legacy documents. The ability to have both as International Standards
was something that needed to be decided by the market place. ISO and
IEC and their national members provided the JTC 1 infrastructure that
facilitated such a decision by the market players... While the voting
on ISO/IEC 29500 has attracted exceptional publicity, it needs to be put
in context. ISO and IEC have collections of more than 17,000 and 7,000
successful standards respectively, these being revised and added to every
month. This suggests that the standards development process is credible,
works well and is delivering the standards needed, and widely implemented,
by the market. Because continual improvement is an underlying aim of
standardization, ISO and IEC will certainly be continuing to review and
improve its standards development procedures..."

http://www.iso.org/iso/pressrelease/faqs_isoiec29500.htm

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

Make SOA Transactional
Rajiv Ramachandran, IBM developerWorks

In the world of enterprise application integration (EAI), it's essential
that all participating systems operate under an overarching global
transaction so that these systems all return to a consistent state in
case of a failure. With the various systems supporting different protocols,
the transaction semantics must be propagated across these protocols so
they can seamlessly participate in the global transaction. This article
walks you through the steps required to make an example of a common
integration scenario a transactional integration. It provides a simple
example involving an SCA component, an EJB component, a Web service, and
a message queue. The proposed solution uses the approach of defining an
SCA component (BPEL process) as the orchestrator for this integration. It
listens for input on a WebSphere MQ queue and then invokes the EJB
component and the Web service interfaces exposed by the two systems to
which it needs to pass the received data. However, the key for this
solution to implement the requirements as stated in the previous section
is to use the distributed transactional capabilities in WebSphere.
WebSphere acts as the transaction coordinator and manages the above
scenario as a single distributed unit of work that's distributed across
various resource managers that include DB2, Oracle, and WebSphere MQ.
This article shows you how SCA transaction qualifiers, Java 2 Platform,
Enterprise Edition (J2EE) transaction specifications, the Web Service
Atomic Transaction (WS-AT) specification definitions, and WebSphere MQ
setup all work together to create a transactional enterprise integration
solution...

http://www.ibm.com/developerworks/webservices/library/ws-soa-transactional/

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

Requirements of Japanese Text Layout
Toshi Kobayashi and Yasuhiro Anan (eds), W3C Technical Report

W3C reports that participants from four W3C Groups (CSS,
Internationalization Core, SVG, and XSL Working Groups), as part of
the Japanese Layout Task Force, have published "Requirements of
Japanese Text Layout." This document describes requirements for
general Japanese layout realized with technologies like CSS, SVG
and XSL-FO. The document is mainly based on a standard for Japanese
layout, JIS X 4051. However, it also addresses areas which are not
covered by JIS X 4051. A Japanese version is also available. Writing
systems are main part of cultures, together with languages and scripts.
Each cultural community has its own language, script and writing system.
In that sense, the transfer of each writing system into cyber space
is a task with very important responsibility for information and
communication technology. As one of the basic work items of this task,
this document describes issues of text layout in the Japanese writing
system. The goal of this task is not to propose solutions itself but
describe important issues as the basic information for actual
implementations. This task force is an outstanding effort as a bilingual
methodology. Discussion is mainly conducted in Japanese, because of
the Japanese issues, but, minutes and mailing list are written in
English. As a process of the development, the task force held already
one face-to-face meeting with the participating Working Groups. This
document itself was also developed bilingually, and is published
bilingually.

http://www.w3.org/TR/2008/WD-jlreq-20080411/
See also Japanese Layout Task Force: http://www.w3.org/2007/02/japanese-layout/

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

Google Data APIs Patent License
Joe Gregorio, Google Blog

Joe Gregorio, Technical Program Manager of the Google Data APIs Team
wrote: "We've always encouraged other developers to adopt Atom, the
Atom Publishing Protocol, and the extensions that Google has created
on top of those standards, but we realized the issue of patents may
have held back some adopters. Well, those concerns end today as we
are giving a no-charge, royalty-free license to any patents we have
that you would need to implement Atom, AtomPub, or any of those
extensions. The exact license text: 'Subject to the terms and conditions
of this License, Google hereby grants to You a perpetual, worldwide,
non-exclusive, no-charge, royalty-free, irrevocable (except as stated
in this License) patent license for patents necessarily infringed by
implementation (in whole or in part) of this specification. If You
institute patent litigation against any entity (including a cross-claim
or counterclaim in a lawsuit) alleging that the implementation of the
specification constitutes direct or contributory patent infringement,
then any patent licenses for the specification granted to You under
this License shall terminate as of the date such litigation is filed.'
Now the official way to announce such a license for specifications
under the IETF is to register them in the IETF IPR Disclosure Database;
you can read the disclosures yourself in the IETF Disclosure Database.
Google's extensions are also covered by this patent license, and you
can find a link to them on the bottom of the authentication schemes
AuthSub and ClientLogin on our core Google Data extensions and Common
Elements, and on [several] Data APIs... We hope this will encourage
sites who want to expose APIs for things like photos, videos, calendar,
or contacts to reuse our schemas where they can, rather than reinventing
the wheel." In this connection, note Mark Nottingham's muse upon the
possible defect in some of the blanket non-assert declarations, in
his blog "Moving the Goalposts: 'Use' Patents and Standards" -- "It's
become quite fashionable for large IT shops to give blanket Royalty-Free
licenses for implementation of core technologies, such as XML, Web
Services and Atom... IT folk see these licenses, nod their heads and
relief, and assume that all is well; they can use this technology in
their projects without fear of at least a handful of big, bad companies
coming to get them. That's not the case. You see, most of these licenses
are restricted to the implementation of this technology, not its use.
This clears the people who actually write the code that implements the
[XML, Web Services, Atom] parsers, processors and tools, but it doesn't
help the folks that use those things. In effect, the vendors are pooling
together their IP and giving each other free cross-licenses on chosen
technologies -- calling a truce, if you like -- but not including their
users..."

http://googledataapis.blogspot.com/2008/04/google-data-apis-patent-license.html
See also Mark Nottingham's blog: http://www.mnot.net/blog/2008/04/02/use_patents

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

Security for Services and Mashups
Steven Robbins, InfoQueue

Security has become a rising concern in most applications and systems
today. Whether you are building small mashups, enterprise applications,
or a platform for SOA, there are several issues and approaches that
are being discussed. Erica Naone talked about dealing with security
in the world of mashups recently while Bob Rhubart and David Garrison
from BEA discussed securing the services you deploy. Naone talked with
experts in the industry from the OpenAjax Alliance, Microsoft Research,
information security firm Mandiant, and mashup maker JackBe in assessing
the current state and future concerns of mashup security. In general,
the browser security model is not up to the task of providing a model
for security mashups... Most of the industry seemed to indicate that
mashup security is still not a solved problem and will be a rising
concern as Web 2.0 applications become more ubiquitous. Not all
applications are mashups, though and BEA has focused on developers who
are creating services that will be deployed in their organizations...
David Garrison uses BEA's Security Services framework as an example of
how to get it done. Garrison points out that BEA uses a Security Services
framework model within their products and then discussed the fundamentals
of designing such a framework using the AquaLogic Enterprise Security
(ALES) products. Garrison identified that there are 5 major
services/providers in a security services framework and described the
responsibilities of each. The 5 items are: Authentication, Role Mapping,
Authorization, Credential Mapping, and Audit. Unsurprisingly, the listed
items are not really different from a traditional application-focused
security framework.

http://www.infoq.com/news/2008/04/security-for-mashups
See also Garrison's blog: http://dev2dev.bea.com/blog/dgarriso/archive/2008/04/the_value_of_a.html

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

XML Daily Newslink and Cover Pages are sponsored by:

BEA Systems, Inc. http://www.bea.com
EDS http://www.eds.com
IBM Corporation http://www.ibm.com
Primeton http://www.primeton.com
SAP AG http://www.sap.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, 17 April 2008