[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.
-James
More information about the tei-council
mailing list