Re: Threading and ordering

>  I'd like to see other examples from the wild too.

I assume asking the question on xproc-dev would be relevant. It seems to me that there are more fellow XProc-ers out there than here.

Romain.

On 1 oct. 2013, at 18:38, Alex Milowski <alex@milowski.org> wrote:

> What would the default be for this feature? 
> 
> I'd prefer the default to be ordered and if that was the case, it seems like it would rarely be used until someone say: Oh, to get this to work better turn on this obscure feature ...
> 
> ...which would then mean the default should be unordered and I would have to be convinced this is a good thing.
> 
> That said, we should consider this after a bit more discussion against some examples that depend on ordering.  I should look through my pipelines and see if anything really does depend on ordering.  I'd like to see other examples from the wild too.
> 
> 
> 
> On Mon, Sep 30, 2013 at 2:51 AM, Toman, Vojtech <vojtech.toman@emc.com> wrote:
> I have seen people creating steps that have two (or more) input/output ports where one is used for the "main" data that is being processed and the others are used to access additional information about the individual documents. There is a 1-to-1 correspondence between the two, and this approach relies on the exact same order of the documents.
> 
> If the order cannot be guaranteed, I think the proposed document metadata XProc V2 feature might help in some cases, but in general, I think that people who would want to implement any kind of pair-wise operation would be in trouble.
> 
> Ordering of connections is also important for parameters. Without a predictable order, you cannot rely on consistent parameter overriding. Again, this should go away if we replace/drop the current parameters in V2.
> 
> Relaxing the ordering would also have impact on some of the standard steps, for instance p:pack, p:split-sequence (the "initial-only" option), p:wrap-sequence, or p:xquery (again, I have seen people who pass a fixed-order sequence of documents to the step: the initial context item is the primary data to query, and the others are auxiliary resources used by the query).
> 
> So I think I agree with Romain and Norm that having an option to indicate that the order does not matter is probably the most sensible way to go.
> 
> Regards,
> Vojtech
> 
> --
> Vojtech Toman
> Consultant Software Engineer
> EMC | Information Intelligence Group
> vojtech.toman@emc.com
> http://developer.emc.com/xmltech
> 
> > -----Original Message-----
> > From: Norman Walsh [mailto:ndw@nwalsh.com]
> > Sent: Sunday, September 29, 2013 11:49 AM
> > To: Romain Deltour
> > Cc: public-xml-processing-model-comments@w3.org
> > Subject: Re: Threading and ordering
> >
> > Romain Deltour <rdeltour@gmail.com> writes:
> > > That said, this is not a *strict* dependence, we could certainly find
> > > a workaround if the XProc spec was to change. Another option would be
> > > to keep the default behavior and add an option to explicitly declare
> > > when the order doesn't matter, e.g. using an extra attribute on the
> > > p:input and p:output ?
> >
> > Yes, that's about where I've come to in thinking about it. If the order
> > matters, some (in the worst case, all but one) documents will have to
> > be buffered so that they can be delivered in the right order.
> >
> > Giving pipeline authors a way to indicate that order doesn't matter
> > will potentially make some pipelines consume less memory and run
> > faster.
> >
> >                                         Be seeing you,
> >                                           norm
> >
> > --
> > Norman Walsh
> > Lead Engineer
> > MarkLogic Corporation
> > Phone: +1 512 761 6676
> > www.marklogic.com
> 
> 
> 
> 
> -- 
> --Alex Milowski
> "The excellence of grammar as a guide is proportional to the paucity of the
> inflexions, i.e. to the degree of analysis effected by the language
> considered."
> 
> Bertrand Russell in a footnote of Principles of Mathematics