May be one could minimize everything to a very very small core.

If you did that, you'd essentially come up with HTML::Template. People have obviously decided that, for whatever reason, HTML::Template doesn't solve their problems and have looked elsewhere.

I do not see why your arguments weren't the same for DBI/DBD which was a hit.

Even though various relational databases do the details differently, their conceptual functionality is the same, and they even use the same query language (more or less) to get the job done. Further, Cobb laid down the basic functionality an RDBMS must provide. The abstraction is straightforward (even if the implementation is difficult).

Although you could make the decision that a template system should generate a defined output for a given input, the details of how this is acomplished vary so widely that I doubt it would work. It would have to be so far abstracted from the real template system that nobody except HTML::Template users would be happy with it. (Which is a long, rambling way of getting back to my first point).

Aha TT3 sounds interesting. But as long we have the other 999 CPAN templating engines we will have different preferences.

If TT3 lives up to its initial promise you'll have a system that can be used to implement all of those 999 CPAN templating engines. A system that will allow you to share common elements (e.g. caching mechanisms) while still taking advantage of whichever template style you find most useful.

May be one could minimize everything to a very very small core. May be that would be usefull and people could improve it?

Then you will essentially end up with HTML::Template. Which is nice, but doesn't meet everyone's needs. One of the reason there are different templating systems is that they do different things in (usefully) different ways. Somebody who builds their application with TT2 templates and plugins will have a completely different structure from somebody building their application with HTML::Template which would, in turn, be different from somebody building an application with AxKit.

You can, of course, have long and interesting arguments about which would be the best model for an application. However there isn't any way you can map a series of transformations in the AxKit style, or something written using TT2s plugins and template language, back to HTML::Template.

With a unified system the lowest common denominator is going to be too low to be useful to many people.

I do not see why your arguments weren't the same for DBI/DBD which was a hit. When DBI/DBD did an API unification job, then "TPI" has also good chances? Or would we need something like SQL for template engines?

The main reason it's different is that DBI/DBD has a single powerful model that unifies all the data sources that it talks to - the relational data model of tables and columns queried with SQL.

I don't pick databases because of the relational model - it's a given. I want to do the same sort of operations to an SQLite database as I do with an Oracle database so it makes sense to have a common way of communicating with them.

When you use DBI to look at things that aren't RDBMs, like Excel spreadsheets, it's because you want to leverage the power of that relational model.

You don't see DBI interfaces to XML based databases, or OODBs, or Prevalence style persistence layers because the conceptual model is different. The reason you would choose an OODB or a Prevalence persistence layer is because you don't want a relational model - so DBI would make no sense.

The same is true of template systems. I pick TT2 over HTML::Template or HTML::Template over AxKit because they have different ways of approaching the world. There can't be a common interface because their models are fundamentally different. Having an interface to TT2 that also worked with HTML::Template would remove the reason I would use TT2 in the first place.