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

Re: subpipelines, Vnext and extension elements redux

From: Jeni Tennison <jeni@jenitennison.com>
Date: Tue, 18 Mar 2008 20:30:05 +0000
Message-ID: <47E0264D.4000705@jenitennison.com>
To: public-xml-processing-model-wg@w3.org

Henry S. Thompson wrote:
> So, we appear to have at least four choices:
> 
>  1) Add a p:declare-compound-step, and try to specify what constraints
>    _don't_ hold of subpipelines with unimplemented compound steps in
>    them;
> 
>  2) Loosen the syntax so that unknown elements are assumed to be
>     unimplemented compound steps and are ignored;
> 
>  3) Go back to the idea of extension namespaces, and treat unknown
>     elements _in an extension namespace_ as unimplemented compound
>     steps;
> 
>  4) Accept that there is no backward-compatible way to introduce
>     new/extension compound steps, and therefore that they will cause
>     static errors in implementations which don't know about them.
> 
> I guess after all this I prefer (4), on the grounds that (1) is just
> too messy, (2) gives up too much, (3) doesn't allow for new compound
> steps _in the pipeline language_ in a backward-compatible way, and
> anyway, the chances of a workaround being available which would enable
> one to write backwards-compatible pipelines using new/extension
> compound steps is so small that there's no point in buggering with the
> language to make that possible.

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.

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.

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. (Isn't this 
what 2.9 Versioning Considerations says already?) That wouldn't help 
with implementation-defined compound steps, but I don't care as strongly 
about them.

Cheers,

Jeni
-- 
Jeni Tennison
http://www.jenitennison.com
Received on Tuesday, 18 March 2008 20:30:42 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 18 March 2008 20:30:43 GMT