[tei-council] Criteria for TEI Repository Inclusion

James Cummings James.Cummings at oucs.ox.ac.uk
Wed Mar 3 06:50:28 EST 2010

Sebastian Rahtz wrote:
> On 3 Mar 2010, at 11:36, James Cummings wrote:

> Your arguments apply just as much, or not, to eg Javascript
> code or Python programs.  Whether a wiki is the right place
> to manage .xml or .py has no relation to whether its doc or code -
> its structured computer language.

Yes, many of which you can cut and paste from wikis around the 
web. ;-) You were the one claiming that wikis were bad because it 
wasn't for software... all I'm saying is a) ODDs aren't software 
applications and b) we have a place on the TEI wiki where you can 
document customisations (whether you include a copy of it or not).

> Our TEI wiki is a pretty low-class primitive CMS, designed
> for looking after _documents_. It groks a particular
> document markup language, and does it well, which
> is why we use it for collaborative editing. It does not grok
> arbitrary XML (or JS, or Python, or PHP), which makes
> it an unsuitable container for collaborative editing of that 
> type of content.

Yes, but it has also been fairly well used for putting one-off 
XSLT scripts there as well because the TEI provides no other 
centralised place to put community-contributed stylesheets.  This 
comes back really to the heart of what I was trying to get at... 
that TEI-C needs a defined policy of when it adopts 
community-created *stuff* (ODDs, Software, Whatever).  Another 
answer to this is to say there is no policy, but create some 
repository specifically for community-created *stuff*.

> If wikimedia was a higher class of document repository
> like (god help us) Sharepoint, then I might be be convinced.
> But its non-text management is grotesquely primitive.

I don't disagree with that.


More information about the tei-council mailing list