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: <vojtech.toman@emc.com>
Date: Mon, 21 May 2012 02:55:43 -0400
To: <public-xml-processing-model-wg@w3.org>
Message-ID: <F3C7EBECE80AC346BE4D1C5A9BB4A41F2ED2B09260@MX11A.corp.emc.com>
> -----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.


Vojtech Toman
Consultant Software Engineer
EMC | Information Intelligence Group
Received on Monday, 21 May 2012 06:56:26 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:32:50 UTC