XML Daily Newslink. Monday, 21 August 2006

[Robin Cover <robin@oasis-open.org>]

XML Daily Newslink. Monday, 21 August 2006
A Cover Pages Publication http://xml.coverpages.org/
Provided by OASIS http://www.oasis-open.org
Edited by Robin Cover

====================================================

This issue of XML.org Daily Newslink is sponsored
by SAP  http://www.sap.com/

====================================================

HEADLINES:

* First Working Draft for Web Forms 2.0
* Understanding XForms: AJAX, XBL, and XForms.org
* The WS-Metadata Exchange Specification Gets a Face Lift
* Inside Pandora: Web Radio That Listens to You
* XProc: An XML Pipeline Language
* Implementing XML Schema Naming and Design Rules: Perils and Pitfalls
* Of RoHS and Rushed Standards: XML, PDF, IPC, ECD

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

First Working Draft for Web Forms 2.0
Ian Hickson (ed.), Google, Inc.

W3C announced that its Web Application Formats Working Group has
released the First Public Working Draft for "Web Forms 2.0." Web Forms
2.0 is an extension to the forms features found in HTML4's Forms
chapter and the corresponding DOM2 HTML interfaces. Web Forms 2.0
applies to both HTML and XHTML user agents. It provides new strongly-
typed input fields, new attributes for defining constraints, a
repeating model for declarative repeating of form sections, new DOM
interfaces, new DOM events for validation and dependency tracking, and
XML submission and initialization of forms. It also standardizes and
codifies existing practice in areas that have not been previously
documented, and clarifies some of the interactions of HTML form controls
and CSS. HTML4, XHTML1.1, and the DOM are thus extended in a manner
that has a clear migration path from existing HTML forms, leveraging
the knowledge authors have built up with their experience with HTML
so far.  The specification is in no way aimed at replacing XForms 1.0,
nor is it a subset of XForms 1.0.  XForms 1.0 is well suited for
describing business logic and data constraints. Web Forms 2.0 aims to
simplify the task of transforming XForms 1.0 systems into documents
that can be rendered on HTML Web browsers that do not support XForms.

http://www.w3.org/TR/2006/WD-web-forms-2-20060821/
See also W3C Rich Web Clients: http://www.w3.org/2006/rwc/

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

Understanding XForms: AJAX, XBL, and XForms.org
Kurt Cagle, O'Reilly Technical

I see XForms becoming very big within the next few years, perhaps in
many ways as important as XHTML itself will likely end up being. I've
begun developing commercial applications around XForms, something which
I will discuss in a few months when it might less jeopardize the
endeavors, but I keep coming back to this interesting paradox. The
applications which I build exist almost exclusively within the
constraints of the XML space. The server side code I need is
lightweight to the point of absurdity, coming as it did from a
decision to avoid getting wrapped up in frameworks. I transform code
with XSLT and EXSLT, perform validation of business logic with
schematron and more transformations, generate forms from schemas
balanced by a separation of presentation layers via CSS, use XForms
and XBL on the client to build the interfaces and marshal the results,
again coupled with the occasional transform or query, and I use an
XQuery interface and some limited Sparql processing to provide some
semantic business rules constraints. The curious thing is that the
applications, ones that in other frameworks end up taking man-years
and are notoriously brittle, seem to naturally flow out of the movement
of the XML through the system. I've written in the past about the
kudzu nature of XML -- that once you introduce XML into a system it
tends to induce a phase shift within that system, replacing complex
semantics with neutral abstractions and just-in-time semantic
resolution. XForms is a key to this process: once you introduce it
into your systems you'll wonder why you spent so much time wrapped
up in imperative frameworks.

http://www.oreillynet.com/xml/blog/2006/08/understanding_xforms_ajax_xbl.html
See also XML and Forms: http://xml.coverpages.org/xmlForms.html

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

The WS-Metadata Exchange Specification Gets a Face Lift
Umit Yalcinalp, Blog

The Web Services Metadata Exchange (WS-MetadataExchange) specification
was released in an updated Version 1.1.  The specification "defines how
metadata can be treated as [WS-Transfer] resources for retrieval
purposes, how metadata can be embedded in Web service endpoint
references, and how Web service endpoints can optionally support a
request-response interaction for the retrieval of metadata. When the
type of metadata sought is clearly known, e.g., WS-Policy, a requester
may indicate that only that type should be returned; where additional
types of metadata are being used, or are expected, or when a requester
needs to retrieve all of the metadata relevant to subsequent
interactions with an endpoint, a requester may indicate that all
available metadata, regardless of their types, are expected. Yalcinalp
writes: "The major change in the WS-MetadataExchange [version 1.1]
specification is the utilization of WS-Transfer. The new version
introduces metadata resources, where specific types of resources for
metadata such as WS-Policy, WSDL, etc. adhere to the WS-Transfer
protocol to enable retrieval of the specific type of metadata they
support. The optional bootstrapping mechanism in WS-MEX is retained,
but it now allows obtaining the specific types of metadata from
dedicated metadata resources that support the WS-Transfer/GET
protocol..."

https://weblogs.sdn.sap.com/pub/wlg/4202
See also the bibliographic update: http://xml.coverpages.org/ni2004-09-21-a.html#ws-mex-200608

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

Inside Pandora: Web Radio That Listens to You
Brad Fuller, O'Reilly Digital Media

The magic of Pandora derives from a simple principle: a song listeners
enjoy should lead to other songs they'll enjoy. Pandora is an Internet
music service with an unusual twist: you merely select a song or artist
you like and the system builds a playlist of additional songs based on
those musical characteristics.  After Pandora builds the playlist, the
music starts streaming to your Web browser -- for free. You can then
refine the playlist by clicking a thumbs-up or thumbs-down button as
subsequent songs play. Other buttons call up more information on the
song or the artist or whisk you to Amazon or the iTunes Music Store to
buy the CD or file. More than 50 percent of the music Pandora receives
makes it to the Music Genome Project after passing through the human
quality filter: people review every magazine and blog about interesting
music, to plumb the Creative Commons depths and find great new music,
and to put the very best on the air. With the exception of the final
user interface, which runs in Flash, Pandora is based primarily on
open source software. The foundation is the PostgresSQL database
running in Debian Linux, with the client tier developed in OpenLaszlo.
The server-side infrastructure is mostly Java running in a J2SE servlet
container. Database access, the playlist generator, and station and
feedback management all live in this Java tier. Pandora creates
playlists with a "matching engine," written in C and Python, for each
listener station. This engine builds the low-level linkage to the
"source" music (the music that listeners indicate they like) and the
music that actually gets played  -- a mixture of what the listener
explicitly indicated, mixed with music that the Pandora service
believes listeners will like. The replication system is Slony. The
listener runs the Pandora service in a web browser, seeing a mixture
of HTML and Ajax techniques for ad delivery and Flash for music
delivery.

http://digitalmedia.oreilly.com/pub/a/oreilly/digitalmedia/2006/08/17/inside-pandora-web-radio.html

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

XProc: An XML Pipeline Language
Norman Walsh,

At Extreme Markup Languages 2006, Norm Walsh gave a 'late breaking'
presentation about the work of the W3C XML Processing Model Working
Group. The XML Processing Model Working Group was chartered to explore
whether an XML-based system can determine whether the creator of any
given XML document has indicated that operations on that document
should be performed in a specific order for a particular result, and
if so, how to apply those operations. This might take the form of
reference to an external document in the XML Processing language, or
some form of annotation regarding the self-describing aspects of the
document.  The Extreme presentation summarizes the state of the W3C
work, fresh from a second face-to-face meeting. The use cases and
requirements were covered briefly, followed by an exploration of
some of the points of consensus and contention. In "XProc: An XML
Pipeline Language", an XML Pipeline describes a sequence of
operations to be performed on a collection of input documents.
Pipelines take zero or more XML documents as their input and produce
zero or more XML documents as their output. Components in the
pipeline may read or write non-XML resources as well. Each operation
in a pipeline is performed by a component. Like pipelines, components
take zero or more XML documents as their input and produce zero or
more XML documents as their output. The inputs to a component come
from the web, from the pipeline document, from the inputs to the
pipeline itself, or from the outputs of other components in the
pipeline.

http://nwalsh.com/docs/presentations/extreme2006/xproc.pdf
See also the abstract: http://www.extrememarkup.org/extreme/2006/e06-tuesday.html#walsh

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

Implementing XML Schema Naming and Design Rules: Perils and Pitfalls
Joshua Lubell, et al., Presentation at Extreme Markup 2006

Organizations developing XML schemas often establish NDRs (Naming and
Design Rules) in order to maximize interoperability and quality. NDRs
are a good way to help enforce best practices, a particular modeling
methodology (such as the CCTS -- Core Components Technical Specification),
or conformance to standards such as ISO 11179 (Naming and Design
Principles for Data Elements). But no single set of Naming and Design
Rules can satisfy everyone's requirements. As a result, NDRs are
proliferating. And new groups embarking on XML schema development are
asking, 'Should we create our own NDR, or should we use a pre-existing
one?'  To help address proliferation and reuse, the National Institute
of Standards and Technology (NIST) is building a QoD (Quality of Design)
software tool kit to make it easier for schema developers to choose
and apply an appropriate NDR set. A Web-based prototype allows users
to upload a schema and select rules from a cross-section of NDRs to
check the schema against. The prototype's purpose is to provide a
user-friendly environment for checking XML schema design quality in a
collaborative environment. The rules are encoded in either the
Schematron assertion language or in the Jess (Java Expert System Shell
- Jess) expert system rule language.

http://www.idealliance.org/papers/extreme/proceedings/html/2006/Lubell01/EML2006Lubell01.html
See also NDR references: http://xml.coverpages.org/ndr.html

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

Of RoHS and Rushed Standards: XML, PDF, IPC, ECD
Peter Seebach, IBM developerWorks

The EU has adopted a set of governmental standards for reduction of
the use of hazardous materials in electrical and electronic equipment.
Although the basic goals of RoHS were finalized in February 2003, the
official standard for this, IPC-1752, was developed extremely quickly,
and became available in February 2006. The IPC-1752 standard was a bit
late, but worse, it was rushed. It's PDF and XML. You may think this
sounds like I'm confused; I am. Apparently they decided on a PDF form
as the "standard," but there's some magic to allow it to import
information from an XML file in a specified form. Unfortunately,
retooling and redesigning take time. Companies that needed to be
compliant by July of 2006 had been working on compliance for years
already. For the most part, this meant a series of unrelated ad-hoc
solutions which might not interoperate. In short, standards hell...
Lessons: In hindsight, one observation is that the specification of
what data needs to be available to a potential parts user is logically
distinct from the question of how this data should be transmitted. The
XML Schema will be used by a lot of people who have no interest in the
PDF format; a smaller, better-documented standard for the XML Schema
alone would have been of great value, and might have been published
sooner, letting more people start experimenting with layers on top of
this that met their business models. On the other hand, divide-and-
conquer isn't always a viable plan. If you have to wait for one
standard to be done before even starting on another, that can make it
harder to comply with a tight schedule.

http://www-128.ibm.com/developerworks/power/library/pa-spec17/

----------------------------------------------------------------------
Cover Pages Sponsors
----------------------------------------------------------------------

BEA Systems, Inc.         http://www.bea.com
IBM Corporation           http://www.ibm.com
Innodata Isogen           http://www.innodata-isogen.com
SAP AG                    http://www.sap.com
Sun Microsystems, Inc.    http://sun.com

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

Newsletter subscribe: xml-dailynews-subscribe@lists.xml.org
Newsletter unsubscribe: xml-dailynews-unsubscribe@lists.xml.org
Newsletter help: xml-dailynews-help@lists.xml.org
Cover Pages: http://xml.coverpages.org/

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