- From: Innovimax W3C <innovimax+w3c@gmail.com>
- Date: Mon, 21 May 2012 09:15:25 +0200
- To: vojtech.toman@emc.com
- Cc: public-xml-processing-model-wg@w3.org
Vojtech, I respectfully disagree here with your reasonning : we could have said that we connect the "error" port on the "p:try" (the same way we connect the "current" port on the "p:for-each" My point is not to defend that we were right : my point is could we be more consistent Mohamed On Mon, May 21, 2012 at 8:55 AM, <vojtech.toman@emc.com> wrote: >> -----Original Message----- >> From: Innovimax SARL [mailto:innovimax@gmail.com] >> Sent: Sunday, May 20, 2012 10:53 AM >> To: XProc WG >> Subject: Naming issue on Compound Steps in XProc 1.0 REC >> >> Dear all, >> >> Following a discussion that has appeared on >> public-xml-processing-model-comments@w3.org by our fellow Norm >> >> [[ >> If the pipeline author does not provide an explicit name, the >> processor manufactures a default name. All default names are of the >> form "!1.m.n..." where "m" is the position (in the sense of counting >> sibling elements) of the step's highest ancestor element within the >> pipeline document or library which contains it, "n" is the position of >> the next-highest ancestor, and so on, including both steps and >> non-step wrappers. For example, consider the pipeline in Example 3, "A >> validate and transform pipeline". The p:pipeline step has no name, so >> it gets the default name "!1"; the p:choose gets the name "!1.1"; the >> first p:when gets the name "!1.1.1"; the p:otherwise gets the name >> "!1.1.2", etc. If the p:choose had had a name, it would not have >> received a default name, but it would still have been counted and its >> first p:when would still have been "!1.1.1". >> ]] >> >> This sentence suggests that p:when and p:otherwise could get a name, >> which is obviously not true (in this case the name is the one of the >> p:choose so this example should be fixed, but it clearly illustrate >> the inconsistency) > > Why is it "obviously not true"? Note the phrase "including both steps and non-step wrappers" in the above definition - from there it follows that things like p:when/p:otherwise or p:catch do get implicit names. > > The difference between p:when/p:otherwise and p:catch that I see is that p:catch has the "error" port which you can refer to (using p:catch's name), but p:when/p:otherwise has nothing you can refer to. That is, as I see it, the reason why p:catch has the @name attribute, but p:when/p:otherwise don't. > > But that p:when/p:otherwise get an implicit name is still a good thing, because it helps, for instance, diagnosing failing pipelines easier. Also, at least conceptually, a name on p:when/p:otherwise is needed so that the processor knows what to connect to inside p:choose. > >> >> But for p:try, we made another choice (which lead Norm to question and >> more specifically lead Henry to forbid the @name on p:catch) > > Like I said above, I think p:try/p:catch is slightly different from p:choose/p:when. > > > Regards, > Vojtech > > > -- > Vojtech Toman > Consultant Software Engineer > EMC | Information Intelligence Group > vojtech.toman@emc.com > http://developer.emc.com/xmltech > > > -- Innovimax SARL Consulting, Training & XML Development 9, impasse des Orteaux 75020 Paris Tel : +33 9 52 475787 Fax : +33 1 4356 1746 http://www.innovimax.fr RCS Paris 488.018.631 SARL au capital de 10.000 €
Received on Monday, 21 May 2012 07:16:00 UTC