I'm not saying we shouldn't publish fabulous unimplemented
specifications we'd like to see implemented; as you point out we have a
tried-and-true role in this regard.
What I'd like to discourage is publishing unimplemented specifications
while down-playing the fact that they're unimplemented. That's a real
trap for new entrants in the field.
[In retrospect I should have picked a more gender-neutral term than
On 26/01/13 14:14, Syd Bauman wrote:
> Perhaps I'm just a grey-beard (hard to think of myself that way), but
> I could scarcely disagree more. The TEI is an encoding specification.
> It is not, and should not be, the TEI's job to build implementations
> (although it has done that at times) nor to search the world over to
> find others' implementations. Besides, I think Sebastian's
> terminological quandary is a pretty big, serious one.
> The TEI should not shy away from recommendations just because there is
> no current implementation. (Although we should try to shy away from
> that which would be very hard or impossible to implement.) And allow me
> to earn my grey-beard cred by reminding that when the TEI started,
> there were *no* implementations of *anything* for a long time.
> Another example: where would the world be if TEI didn't develop and
> publish the extended pointer syntax? To my knowledge it was rarely
> used and never implemented. But it is the foundation of XPath.
> And I don't think the TEI is any danger of becoming a cul de sac at
> all. (That said, I do worry that <cRefPattern> itself will become
> exactly that. Which is a bit surprising, I think, as I think it is
> potentially quite useful and can't be *that* hard to implement, can
>> You're welcome to recast the note without term you find offensive,
>> but neglecting to warn newbie users of serious issues just because
>> the grey-beards have a terminological quandary is asking for TEI to
>> become a cul de sac.