- From: Alex Milowski <alex@milowski.org>
- Date: Wed, 04 Oct 2006 09:48:35 -0700
- CC: public-xml-processing-model-wg@w3.org
Jeni Tennison wrote: > > Hi Alex, > > OK, I'm persuaded by your argument that if there's no technical reason > for components to be ordered then users should be able to order them in > whatever way makes sense to them. If they choose to use an order that > makes their pipeline hard to maintain or follow, that's up to them. > > However, given that we have no other way of indicating out-of-band > dependencies, I do think step order needs to be significant. If a user > writes > > <p:step name="C" ...> > <p:input port="doc" step="A" source="result" /> > <p:input port="aux" step="B" source="result" /> > </p:step> > <p:step name="A" ...>...</p:step> > <p:step name="B" ...>...</p:step> > > and (implicitly) step A depends on step B, then the user will want step > A to be performed before step B. Right now step ordering is done via input and output dependencies. I don't want to change that. > In other words, the explicit dependencies between steps provide a > partial ordering; where the explicit dependencies do not specify an > ordering between two steps, the result must be as if the implementation > performed the steps in the order given in the pipeline specification. I don't believe we can codify that because that relies on a explicit definition of the graph structure. We've decided to avoid explicitly describing the graph and such a statement about document order makes me very uncomfortable. If there is an issue with explicit ordering and users need a way to dictate that, I'd rather have an explicit "before" construct in the language. I think that many users just will not care because they are concerned about the inputs and outputs. In the case where they have side-effects that they need to order, they'll need a better way than document order in which to describe that constraint. --Alex Milowski
Received on Wednesday, 4 October 2006 16:48:48 UTC