W3C home > Mailing lists > Public > public-xml-processing-model-wg@w3.org > October 2012

ACTION A-220-04

From: Toman, Vojtech <vojtech.toman@emc.com>
Date: Fri, 5 Oct 2012 09:56:18 -0400
To: XProc WG <public-xml-processing-model-wg@w3.org>
Message-ID: <F3C7EBECE80AC346BE4D1C5A9BB4A41F2EE72F953B@MX11A.corp.emc.com>
Hi all,

I took a deeper look at ACTION A-220-04
(http://lists.w3.org/Archives/Public/public-xml-processing-model-comments/2012Jul/0002.html).

It turns out to be more interesting than it seemed at the first glance. The main
issue is that on one hand we say that p:when/p:otherwise are just wrappers and
not steps, yet at the same time we seem to assume that they behave as compound
steps ("If a compound step has no declared outputs and the last step in its
subpipeline has an unconnected primary output, ..." etc.). The same applies to
p:group/p:catch in p:try.

There are two ways of fixing this (both of them require more or less the same
amount of changes, but have different implications):

1. Make p:when/p:otherwise in p:choose and p:group/p:catch in p:try compound
   steps and get rid of the notion "non-step wrapper". This might require some
   tweaks here and there (the definition of what "container" meens for
   multi-container steps would have to change), but I think it could work.

2. p:when/p:otherwise in p:choose and p:group/p:catch in p:try are really just
   wrappers, in which case we will have to make sure that the rules in sections
   2.2 (Inputs and outputs) and 2.3 (Primary Inputs and Outputs) apply to
   non-step wrappers as well.
   By the way, does anybody beside me find it weird that in the current
   specification, p:group can be *both* a compound step and a non-step wrapper
   (in p:try)?

What were our original intentions? Personally, I think the notion of a non-step
wrapper is not necessary, but others may think otherwise (or perhaps getting rid
of it might be too big of a change for an erratum?).

Another issue that applies in either case is that the current prose about
p:choose and p:try gives the impression that a subpipeline can have output
ports. That clearly is not the case; only steps can.

What do you think?

Regards,
Vojtech


--
Vojtech Toman
Consultant Software Engineer
EMC | Information Intelligence Group
vojtech.toman@emc.com
http://developer.emc.com/xmltech
Received on Friday, 5 October 2012 13:56:56 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 5 October 2012 13:56:57 GMT