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

Re: subpipelines, Vnext and extension elements redux

From: Norman Walsh <ndw@nwalsh.com>
Date: Tue, 18 Mar 2008 16:37:18 -0400
To: public-xml-processing-model-wg@w3.org
Message-ID: <m2skynwyyp.fsf@nwalsh.com>
/ Jeni Tennison <jeni@jenitennison.com> was heard to say:
| What about doing what XSLT does and having a p:fallback element that
| must be present in any extension/Vnext compound steps. If the
| processor encounters an unknown element, it must execute the
| p:fallback child of that element if it has one. If it doesn't have a
| p:fallback child then it's a static error.

We could, I guess.

| I'm generally happy to go along with (4) if there's no other
| acceptable way, though I'm not happy that it means that if a new
| compound step is introduced in Vnext, people won't be able to use it
| in their pipelines without making their pipelines unrunnable in v1
| implementations.

It would.

| Actually, to just deal with Vnext compound steps, couldn't we use the
| forward compatibility rules: make unknown elements dynamic errors in
| forwards compatibility mode and static errors otherwise.

No, I don't think so, because static analysis can't be performed in
the face of unknown compound steps. The processor has know way to know
what its inputs and outputs might be.

                                        Be seeing you,

Norman Walsh <ndw@nwalsh.com> | It would not be better if things
http://nwalsh.com/            | happened to men just as they wished.--
                              | Heraclitus

Received on Tuesday, 18 March 2008 20:37:53 UTC

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