Re: Directed vs. Generic syntax reprise

/ Jeni Tennison <jeni@jenitennison.com> was heard to say:
| I think there are two sets of syntax-level options we have to explore:
|
| 1. directed vs. generic syntax (e.g. implicit/explicit steps)
| 2. defaulting attributes, elements, steps (e.g. input/output names)
|
| This mail discusses the first. To summarise, I'd be happy with either
| syntax as long as elements (rather than attributes) were used to
| represent inputs/outputs/parameters.

+1

| I also hope we don't end up with
| a situation there are options such that different users or different
| components use different syntax.

+10 :-)

| There's a real continuum between directed and generic syntax. 

Indeed.

| From
| completely generic syntax:
|
| <p:step name="p:xslt">
|   <p:input name="source" ref="..."/>
|   <p:input name="stylesheet" ref="..."/>
|   <p:output name="result"/>
| </p:step>
|
| through using the name of the element to indicate the component:
|
| <p:xslt>
|   <p:input name="source" ref="..."/>
|   <p:input name="stylesheet" ref="..."/>
|   <p:output name="result"/>
| </p:xslt>
|
| through using directed syntax elements for the inputs/outputs/parameters:
|
| <p:xslt>
|   <p:source ref="..."/>
|   <p:stylesheet ref="..."/>
|   <p:result/>
| </p:xslt>
|
| to using directed syntax attributes for the inputs/outputs/parameters:
|
| <p:xslt source="..." stylesheet="..."/>
|
| There's obviously also the possibility of allowing more than one of
| these syntaxes (in the way that RDF does), but I think we should avoid
| that if at all possible.

+1

| There's also the possibility of having different components have
| different XML structures for their steps. Again, I think we should try
| to avoid that if we can, as it would raise the barrier on learning to
| put together pipelines.

Yep.

| [Note: I know that XSLT extension elements are essentially the same
| thing and XSLT users have been able to manage. One big difference is
| that XSLT is inherently un-validatable using most schema technologies,
| so XML editors have built-in auto-completion assistance rather than
| using schemas. We want XProc to be validatable using XML Schema & RELAX
| NG. Another is that XSLT extension elements are relatively thin on the
| ground compared to the built-in XSLT elements, and I'm not sure whether
| we're going to have a similar situation here: what's the proportion of
| built-in components vs. engine-specific components going to be?]

Yeah, this is an important factor, but I'm not sure how to predict it
with any accuracy. One thought that I had was to start an "exproc"
project sooner rather than later so that all the common extensions are
more likely to land in a single namespace.

| As I say, I'm undecided.

Me too.

If we name inputs and outputs by putting explicit labels on each
input/output ("styleresult"), then I think I favor the completely
generic syntax.

If we name inputs and outputs by reference to the standard names of
configured components ("style/result"), then I think I have a very
small preference for the directed syntax for components (basically,
because <p:step name="p:xslt" xml:id="style"> seems cumbersome)

The directed syntax for inputs/outputs/parameters doesn't appeal to
me.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh
XML Standards Architect
Sun Microsystems, Inc.