Re: subpipelines, Vnext and extension elements redux

Hash: SHA1

Jeni Tennison writes:

> 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.

Well, I feel like compound steps are more like XSLT top-level elements than
XSLT instruction elements.  You can't extend XSLT with a new kind of
template, for example.

> 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.

Well, that's exactly what would happen if XSLT ever introduces a new
kind of template.

> 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.

Hmm.  I'm not sure treating p:foreach one way in normal mode and
another in forward compatibility mode is a service to users. . .

> (Isn't this what 2.9 Versioning Considerations says already?)

I don't think so -- you can only avoid the static error if there's a
p:declare-step for your element in the Vnext canonical library.

- -- 
 Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh
                     Half-time member of W3C Team
    2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440
            Fax: (44) 131 650-4587, e-mail:
[mail really from me _always_ has this .sig -- mail without it is forged spam]
Version: GnuPG v1.2.6 (GNU/Linux)


Received on Wednesday, 19 March 2008 15:56:44 UTC