W3C home > Mailing lists > Public > public-xml-processing-model-comments@w3.org > July 2009

RE: Compound steps with unconnected output ports

From: <Toman_Vojtech@emc.com>
Date: Mon, 20 Jul 2009 02:54:20 -0400
Message-ID: <6E216CCE0679B5489A61125D0EFEC787103ED00C@CORPUSMX10A.corp.emc.com>
To: <public-xml-processing-model-comments@w3.org>
> > Also, would there be any difference if I declared "foo" as
> > sequence="true"?
> If you don't specify sequence=true, then I think you get an 
> error because
> you can't send an empty sequence to a port that doesn't 
> accept sequences.
> If you do specify sequence=true, then you just get an empty 
> sequence on
> that port.

Where does this follow from? Maybe I am missing something obvious, but I
don't see anything that says this in the spec.
It seems to me that at the moment, unconnected output ports may simply
produce *nothing* (that is, not even am empty sequence) simply because
this area is uncovered by the spec. Err:XD0007 can probably deal with
non-sequence outputs, but what about sequence outputs? 

Btw, Calumet does exactly what you said in your reply: you get an empty
sequence of documents for unconnected "sequence" output ports and
err:XD0007 for unconnected "non-sequence" output ports. I may be wrong,
but I see this more as a coincidence than a direct result of
implementing the spec.

I think that (unless it is already somewhere in the spec and I have
missed it, which is not that unlikely) we should make the semantics of
unconnected output ports in compound steps mode clear.

> It's statically valid in either case.

...I tend to agree - at least in the sense that there is no error
defined for this case.

> > The only thing I found is in section 2.2:
> >
> > "Within a compound step, the declared outputs of the step *can* be
> > connected to: ..."
> > (Notice that the sentence uses "can", not "must".)
> Since that's a p:pipeline, the identity step will get connected to the
> primary result port. If it was a declare step, you'd get a 
> static error
> because the primary output port of the identity step would be unbound.

I am aware of that. To avoid any confusion because of using p:pipeline,
here is something else:

<p:declare-step xmlns:p="http://www.w3.org/ns/xproc">
  <p:input port="source"/>
  <p:output port="result" primary="false" sequence="true"/>

Received on Monday, 20 July 2009 06:55:09 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:28:26 UTC