brian asked:
Couldn't most of this be figured out by making Pod6 extensible (or
whatever the right term is). Pod6 would be more of the syntax and basic
operation, but other people could have custom directives that their
Pod6 translators and formatters could then use. That is, not all of
this has to be in the spec if the spec has a way to make it possible
later. :)
Yes. That's exactly what we've done. Pod 6 has:
=item a C<=use> directive that allows you to load behaviours for
any user-defined blocks or formatting code you want
=item a standard mechanism by which user-defined blocks are available
(just make the block names mixed-case)
=item a standard mechanism for adding new formatting codes (the M<> metacode)
And, as far as writing a new S26, does this mean that this really isn't
open to discussion? That is, if we want something different than you
want we have to have competing specs and there won't be any compromise?
Of course not. Indeed it's a *plea* for something more concrete to discuss, a
suggestion of a way to get past the philosophical impasse of one group saying
"this does everything you want", without nailing down the specifics of how,
whilst another says "this isn't good enough", without clearly indicating what
would be.
What I was actually suggesting was that this design *isn't* set in stone, and
that the best way to convince Larry that the existing design could be better
is to actually offer a better design.
Damian
