Re: [EXTERNAL] - Getting rid of @sequence="true/false"?

Hi,

Getting rid of @sequence seems like a good idea to me. I know I've had it
set to false on numerous occasions, only to get weird errors and an 'oh'
moment when realising why. Having everything be a sequence makes sense to
me.

Having said that, I like #3 but need to think about it more.

Thanks,

/Ari


On 22 September 2017 at 15:05, Vojtech Toman <vtoman@opentext.com> wrote:

> I think removing sequence=true/false is a good idea. In the ideal world,
> everything is a sequence :)
>
> My personal favorite is option 2. (To be honest, I don't quite understand
> option 1 - is this some sort of backward compatibility mode for old XProc
> 1.0 pipelines?)
>
> Option 3 (implicit looping) looks fancy but I think it would work only
> with simple steps that have only one input port. For steps that have
> multiple non-sequence input ports, it is far from clear to me how it could
> work. Would it loop? Would it loop over all combinations of the inputs
> (implications on streaming)? Etc. Also, there would probably have to be
> some mechanism to tell the processor whether it should loop over a port or
> not (because sometimes you do want to pass a sequence of items to the
> step). Consider, for example, the p:xquery step: it takes a sequence of
> documents on the "source" port (the default collection) and the XQuery on
> the "query" port. You definitely don't want to loop over "source" but you
> may or may not want to looping over "query".
>
> Regards,
> Vojtech
>
> -----Original Message-----
> From: Achim Berndzen [mailto:achim.berndzen@xml-project.com]
> Sent: Friday, September 22, 2017 2:41 PM
> To: XProc Dev
> Subject: [EXTERNAL] - Getting rid of @sequence="true/false"?
>
> Hi all,
>
> A while ago, @ndw and I had a mail conversation about sequence ports in
> XProc 3.0. In order to make it easier to learn XProc, we discussed about
> elimination non-sequence ports and @sequence, so that in XProc 3.0 all
> steps accept sequences on all ports.
>
> Following this line of thought, some options are possible:
>
> 1. Nothing changes: All steps accepting sequences on a port in XProc 1.0
> will do so in XProc 3.0. Steps that do not accept a sequence will only
> raise an error, when an empty sequence is delivered. If not, they we
> process the first document in the sequence as described and discard all
> others.
>
> 2. We simply move task of raising an error to the step and its semantic:
> Instead of having one global error (XD0006) we could have more informative
> errors like (XS????: It is a dynamic error if not exactly one document
> appears on port "stylesheet"
> of p:xslt).
>
> 3. Implicit looping: One possible consequence I personally like very much
> is the idea, that some steps (like p:add-attribute, p:delete, p:insert
> etc.) do an implicit looping for the sequence. This might be more natural
> the XProc newbies and may appear attractive to current users, because in
> some cases you will not need "p:for-each" any more. This would be inline
> with p:viewport in XProc 3.0 with does implicit looping. For other steps,
> where implicit looping does not make sense (e.g. p:compare or
> p:http-request) we could choose option (1) or (2).
>
> 4. Bad idea, keep it like it is: You might say that the distinction
> between a document and a sequence of documents is very easy to grasp and
> that it is perfectly established in XSLT, XQuery and other X-technologies.
> Also you might argue, that in XProc 3.0 we will have mixed sequences with
> XML and non-XML documents and we would need a special treat when
> p:add-attribute is applied to a sequence of xml documents, JPEGs and texts.
>
> What do you think?
>
> Greetings from Germany,
> Achim
> ------------------------------------------------
> Achim Berndzen
> achim.berndzen@xml-project.com
>
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.xml-
> 2Dproject.com&d=DwIFAg&c=ZgVRmm3mf2P1-XDAyDsu4A&r=aJZr6mdNzy-
> qsGbVYWF8KIxwje5rrbk2V7QfMr35EhU&m=cPHeErshVOYtQvSxAMDAic7JkUGz2H
> P66H7HpBWsndQ&s=mHiMaFmT9YqrWTQHwBnXpOa4VbbxxpA4Y2cOjvacjmY&e=
>
>
>
>
>
>
>
>

Received on Friday, 22 September 2017 13:22:02 UTC