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

Naming issue on Compound Steps in XProc 1.0 REC

From: Innovimax SARL <innovimax@gmail.com>
Date: Sun, 20 May 2012 10:53:14 +0200
Message-ID: <CAAK2GfG==ebTkQSoKrfcbdX8evEisW1==DJZzipDwUbN-MW9jg@mail.gmail.com>
To: XProc WG <public-xml-processing-model-wg@w3.org>
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)

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)

We said the name are the one that are on the p:group and p:catch

Are we consistent here, two naming strategies for what looks like same
compound building blocks ?


Innovimax SARL
Consulting, Training & XML Development
9, impasse des Orteaux
75020 Paris
Tel : +33 9 52 475787
Fax : +33 1 4356 1746
RCS Paris 488.018.631
SARL au capital de 10.000 €
Received on Sunday, 20 May 2012 08:53:45 UTC

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