-----BEGIN PGP SIGNED MESSAGE-----
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.
ht
- --
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: ht@inf.ed.ac.uk
URL: http://www.ltg.ed.ac.uk/~ht/
[mail really from me _always_ has this .sig -- mail without it is forged spam]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFH4TeMkjnJixAXWBoRAs4DAJwKmwk/jVXYW3zaay9POIQrBpetAACfaXpq
XqIPGe/ssxZNqydzDKDT/FI=
=TzlB
-----END PGP SIGNATURE-----