keith said:
>   Evidently, everybody has not to some
>   very important views mentioned here.

i can't parse that, keith.  sorry.


>   P.G does not have any rules that could
>   be used by independent contributors.

sure they do.

but they're all kind of vague.

and none of them are really enforced.

reminiscent of this famous line:
>   the code is more what you'd call
>   "guidelines" than actual rules

anyway...

>   From recent statements DP has some
>   consistency rules, but many ways of
>   doing the same thing. That is not good.

right.  because everyone's doing the job manually.

if you give them a good tool that does the job, and
does it quickly and easily, they will use that instead.

and since the tool will do the task _consistently_,
the output will be uniform, instead of snowflakes.

the problem is that everyone approaches this as
"the postprocessors have to change what they do".
but the postprocessors _do_not_want_to_change_,
because "change" sounds too much like hard work.

but the reality is that -- if you did this correctly --
the approach would be "we'll help you do your job".
with a bonus later of "and hey, it's working better!",
when they learn that this new and easier workflow
actually creates derivative formats that are superior.

everyone's doing it bass-ackwards.  you gotta show
the postprocessors that this is in their best interests.
you've gotta make their life easier, not more difficult.


>   ANA is an attempt to provide guidance
>   towards developing consistency rules.

well, i haven't paid much attention to your scheme,
keith, because you're re-doing something i already
did, a long time ago, and i did it more systematically.

further, i turned my work into an actual test-suite,
so it's something with value for my programming...

i have shown that my code can handle the test-suite,
so i have good confidence it can handle most books
people will throw at it.  that's why you do a test-suite.

otherwise, you waste your time on 300-page books
that consist of little more than plain old paragraphs,
and fool yourself that you "accomplished" something.


>   Once you have those, one can
>   develop tools that abide by these rules.

again, you're 5 years behind me.

i mean, it's nice that you're on the right path.

but beyond that, there's not much i can say...


>   DP has no such consistent model.

even if d.p. had a consistent "model", what matters
is what the volunteers actually _do_.  rules do _not_
guarantee consistency...  they merely "promise" it...

besides, "rules" are a non-starter over at d.p.  sorry.
the people over there don't want to learn your rules.
they already paid their dues, creating their own way.

they _might_ want to save their own time and energy.
so that's the only avenue that's gonna succeed there.

(and since many postprocessors do it for the fun of it,
it's not even clear that "saving time" will be appealing.
but, realistically, it's the only shot you've got.  really.)

so build 'em a tool that will save 'em time and energy.

like the one i've built.

because they aren't gonna want to use the one i built...
because i laugh at their stupidity, and mock their pride,
and i will enjoy it immensely if i can say "i told you so!"

so they sure aren't gonna give _me_ that satisfaction...

but if you code it, or don does, or hunter does, they will.

and hunter has the leading edge right now, because he
isn't going to make them change their workflow one bit.

i would tell them to throw away their silly pseudo-markup.
don would have 'em start using _his_ silly pseudo-markup.

but hunter?  he will let them continue on their merry way...

so it's definitely hunter who is the one who could do this.
unfortunately, he keeps threatening to pull out of the job.


>   those that have a say about how and what gets done are
>   competent in their individual fields, yet they seem to have
>   very little competence in the fine art of computer science.

no comment.            :+)

-bowerbird