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

Re: Naming issue on Compound Steps in XProc 1.0 REC

From: Innovimax W3C <innovimax+w3c@gmail.com>
Date: Mon, 21 May 2012 09:15:25 +0200
Message-ID: <CAAK2GfHvMqhhu_R3eboxAP-tWFJamd3O+NQ-otNx7te-3GDggg@mail.gmail.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 21 May 2012 07:16:02 GMT