Re: XML Processing Model Requirements

Your requirements document made interesting reading to us at 1060
Research. Many years ago in a stealth research project inside
Hewlett Packard Labs we evolved a language called Declarative Processing
Markup Language (DPML) in a project called Dexter which was eventually
spun out of HP and now has a home at http://www.1060research.com/ The
language has evolved considerably since then through extensive use.

It is remarkable how closely your requirements are satisfied by DPML.

Point by point:

The language must be rich enough to address practical interoperability
> concerns.
DPML supports an extensible instruction set which is dynamically discovered
at runtime.
>         
> The language should be as small and simple as possible.
The language has no built in instructions. It has keywords for exception
handling, conditional processing, and iteration.
> 
> The language must allow the inputs, outputs, and other parameters of a
> components to be specified.
Arbitrarily named input and parameters can be specified. In the vain of
functional programming on one output (except by side effect) is possible.
> 
> The language must define the basic minimal set of mandatory input
> processing options and associated error reporting options required to
> achieve interoperability.
We have currently have no meta data definition of a program or service within
the DPML language itself.
> 
> Given a set of components and a set of documents, the language must
> allow the order of processing to be specified.
The order of processing is specified.
> 
> It should be relatively easy to implement a conformant implementation of
> the language, but it should also be possible to build a sophisticated
> implementation that can perform parallel operations, lazy or greedy
> processing, and other optimizations.
Our implementation of DPML is very compact and simple- it is possible to
see how it could made more sophisticated to perform parallel operations,
lazy or greedy evaluation and other optimizations.
> 
> The model should be extensible enough so that applications can define
> new processes and make them a component in a pipeline.
Yes, one DPML process may call another as a subroutine.
> 
> The model must provide mechanisms for addressing error handling and
> fallback behaviors.
We have a mechanism for nested exception handling in which the exception
is available as an XML document. We also present an instruction for throwing
exceptions.
> 
> The model could allow conditional processing so that different
> components are selected depending on run-time evaluation.
We have an "if" and a "choose" instruction. We also have the capability
for iterative processing using the "while" instruction.
> 
> The model should not prohibit the existence of streaming pipelines.
We have examples which do processing on a SAX stream pipeline and examples with
DOM.
> 
> The model should allow multiple inputs and multiple outputs for a
> component.
We allow arbitrary inputs. We allow only one output.
> 
> The model should allow any data set conforming to one of the W3C
> standards, such as XML 1.1, XSLT 1.0, XML Query 1.0, etc., to be
> specified as an input or output of a component.
DPML is dataset neutral. New data types can be dynamically used at runtime
depending upon what are used or presented by the available instructions.
In addition to XML datatypes DPML can support anything from character
streams to image pixel maps and video streams.
> 
> Information should be passed between components in a standard way, for
> example, as one of the data sets conforming to an industry standard.
You have the choice to use industry standard data sets or application
internal optimized ones.
> 
> The language should be expressed in XML. It should be possible to author
> and manipulate documents expressed in the pipeline language using
> standard XML tools.
DPML is expressed in XML though we have received much criticism for this
choice!
> 
> The pipeline language should be declarative, not based on APIs.
The APIs of the underlying data sets and instructions are hidden.
> 
> The model should be neutral with respect to implementation language.
> Just as there is no single language that can process XML exclusively,
> there should be no single language that can implement the language of
> this specification exclusively. It should be possible to interoperably
> exchange pipeline documents across various computing platforms. These
> computing platforms should not be limited to any particular class of
> platforms such as clients, servers, distributed computing
> infrastructures, etc.
We believe this to be the case. Our implementation is written in Java
but there is nothing Java specific.
        
For more details see:
http://www.1060research-server-1.co.uk/docs/1.2.0/book/xmldev/doc_guide_dpml_quick_reference.html
and
http://www.1060research-server-1.co.uk/docs/1.2.0/book/xmldev/doc_dpml_eg_index.html

DPML isn't currently an open specification but our implementation is
open source. However we would have no hesitation in working toward an
open specification.

-- 
Tony Butterfield <tab@1060.org>
1060 Research

Received on Tuesday, 4 May 2004 11:37:59 UTC