[tap-l] Nested TAP

[Michael Peters]

Aristotle Pagaltzis wrote:

> Am I correct in thinking that you can translate this to a back-
> compatible TAP stream merely by inserting an unindented
> `not ok 2` line before the `begin 2` line?

Yes, or it can appear after as a summary line.

> If so, then it is inevitable that someone will have to parse the
> nested TAP, and it’s merely a question of which end that will be.
> 
> If that is the case, why are we trying to dictate the side on
> which this should happen?
> 
> I would argue that instead of pinning the duty on either end, we
> should merely describe how TAP v13 can be downgraded to TAP v12
> and leave it up to individual users of TAP where they want to
> shift that complexity. If push comes to shove, they can write an
> intermediate pipeline step that takes v13 TAP and downgrades it
> in the manner we have described in the spec before sending it to
> their v12 consumer.
> 
> In fact, we should probably make v13 allow both the presence and
> absence of the back-compat shim line. That way, people can write
> v13 producers now that work with v12 consumers now, but those who
> have upgraded their entire infrastructure can shed that crutch.

I'm starting to warm up to this idea. I'm still concerned with the baggage it
adds to the protocol but as long as it's optional it will probably be ignored.
Especially if we recommend that it only be used when integrating with earlier
parsers.

-- 
Michael Peters
Plus Three, LP