Re: What do we standardize?

/ Richard Tobin <> was heard to say:
| I was going to reply to Jeni's message, but realised that I need to
| address a rather wider issue: what are we going to standarize?
| It seems natural to me to divide the problem into several parts:
| - the pipeline language itself.  I call an implementation of this
|   a "pipeline engine";

Yep, I want one of those :-)

| - a set of standard components, such as XSLT and XInclude;

I think we'll need to define a set of components. I'm not sure which
ones will be required and which will be optional. I can imagine that
there are folks who will want an XQuery component, and
interoperability would be improved by having a standard one, but that
doesn't mean I think every conformant processor should have to support

| - a framework for writing additional components that are interoperable
|   with other suppliers' pipeline engines and components;

I'm not sure I want to go there. When the XSLT WG proposed a standard
API for extension functions, the community pushed back.

| - a component description language that would specify such things as
|   the number of inputs and outputs a component has, what parameters it
|   takes, and what infoset extensions it needs.

That's an interesting possibility.

| I separated the third and fourth points because I think the component
| description will be useful even if you only have standard components.
| For example, a pipeline consistency checker or graphical interface for
| building pipelines could use them.


| I think we will find it easiest to first standardise only the first
| two, and in any case there should be a level of conformance that
| allows systems that only provide the first two.  In this case, what
| flows between components need not be specified, since it is internal
| to the implementation.


                                        Be seeing you,

Norman.Walsh@Sun.COM / XML Standards Architect / Sun Microsystems, Inc.
NOTICE: This email message is for the sole use of the intended
recipient(s) and may contain confidential and privileged information.
Any unauthorized review, use, disclosure or distribution is prohibited.
If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.

Received on Tuesday, 10 January 2006 21:56:49 UTC