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.comhttp://developer.emc.com/xmltech