Re: Cocoa texts and conversions?

Some kind of unsupported/ directory at GitHub (@TEI-C or in James' 
space) would be better than the wiki, because people could fork from it 
if they wanted to expand the tool(s). And "unsupported" would explain 
why the modifications are not getting pulled back, but at the same time 
it would keep a record of the forks, for other users in need.

Best,

   P.


On 01/10/2017 05:26 PM, Martin Holmes wrote:
> Obsolete would be better than deprecated. But ideally there would be
> something analogous to deprecation during which you warn users that
> you're intending to stop maintaining a particular feature or conversion,
> and specify a date at which it will be retired.
>
> Cheers,
> Martin
>
> On 2017-01-10 07:10 AM, Lou Burnard wrote:
>> It's not strictly speaking deprecated though, is it? Otherwise it
>> couldn't be considered useful ... quite the reverse in fact! It's just
>> unsupported, or non strategic or minority interest, or something.
>>
>>
>>
>>
>> Sent from my Samsung Galaxy Tab®|PRO
>>
>>
>> -------- Original message --------
>> From: Martin Holmes
>> Date:2017/01/10 13:44 (GMT+00:00)
>> To: [email protected]
>> Subject: Re: Cocoa texts and conversions?
>>
>> Hi James,
>>
>> You're right that we have no mechanisms for deprecation in the
>> Stylesheets. But we could simply move deprecated code to the TEI wiki,
>> where there is already a collection of useful XSLT:
>>
>> <http://wiki.tei-c.org/index.php/Category:XSLT>
>>
>> Cheers,
>> Martin
>>
>> On 2017-01-10 05:07 AM, James Cummings wrote:
>>> Hi Piotr,
>>>
>>> That is partly why I suggested it should be assigned to me (since I know
>>> the original code).  I agree that Council has *more* than enough work
>>> keeping up with maintenance of the Guidelines, as well as the
>>> Stylesheets and other software. This would be very low priority and if I
>>> didn't have time to do it in the next couple releases I'd note as much
>>> on the issue, and either I or someone could remove the cocoa-to-xsl
>>> scripts.  Though I'm curious what should be done when we do so..
>>> previously we've just moved things around as and when we please or got
>>> rid of stylesheets , and that is good, but it might be beneficial to
>>> leave a note as to where these scripts could be found. (i.e. I might
>>> fork just the cocoa-to-xsl and stick it in my repositories in case it is
>>> useful to anyone, including me, in the future.) But then do we have to
>>> maintain that pointer? Maybe best just to delete and leave the existence
>>> of the closed issue on github as documentation. ;-)
>>>
>>> But honest, I'll give it a good 20 minutes of thought in trying to fix
>>> it --  if I can't in that time, then maybe we'll get rid of it.
>>>
>>> -James
>>>
>>>
>>> On 10/01/17 12:26, Piotr Banski wrote:
>>>> Hi James,
>>>>
>>>> I think the only good (or at least acceptable) argument is in your
>>>> last line (plus your request to get this assigned):
>>>>
>>>> > since it used to work I'm suspecting that making its output valid
>>>> again wouldn't necessarily be too difficult
>>>>
>>>> -- otherwise, I can't see why the Council should devote any time to
>>>> up-conversion from COCOA or any legacy format. This should always,
>>>> IMO, be an issue for a local project (formal or informal: funded or
>>>> performed as e.g. a semester assignment or on a friend-to-friend
>>>> basis). I feel scared by the prospect that Council time (including F2F
>>>> time) might get allocated to such matters, seeing the flood of
>>>> _current_ issues at GitHub.
>>>>
>>>> Best regards,
>>>>
>>>>   Piotr
>>>>
>>>>
>>>>
>>>>
>>>> On 01/09/2017 12:57 PM, James Cummings wrote:
>>>>> Hi Martin,
>>>>>
>>>>> Apologies for the delay in answering.  In case anyone is interested
>>>>> in their history: Yes, that initial cocoa-to-xsl script was indeed
>>>>> written by me (and then improved substantially into doing multiple
>>>>> passes by Sebastian with additional debugging output).  My first
>>>>> attempts at doing so were to make the Cocoa file well-formed XML
>>>>> (through wrapping a root element around it, changing any individual
>>>>> tags to be milestone-like psuedo elements) which was done in Perl
>>>>> before using XSLT, and then running that through two stylesheets, one
>>>>> to transform the flat cocoa markup language to a flattened TEI markup
>>>>> language (i.e. rename things) and then the next to fill that
>>>>> flattened TEI with structure (using xsl:for-each-group).  The
>>>>> original files were written in 2004, with the express purpose of
>>>>> being used for a subset of the OTA consisting specifically of verse
>>>>> drama and I even spoke about this at ALLC-ACH 2004 in Gothenburg. The
>>>>> are available for now at
>>>>> http://users.ox.ac.uk/~jamesc/research/cocoa2tei/ where I put them in
>>>>> early 2006. I was doing this in a very modular way with the intent of
>>>>> applying to different sorts of texts as well. Partly this was created
>>>>> to estimate for a (failed) funding bid by the OTA how much work it
>>>>> would take to convert a large portion of the OTA archives all to TEI
>>>>> (whilst maintaining the original files of course).  [If I remember
>>>>> the reviews correctly it failed partly because one reviewer was
>>>>> outraged that mere technicians might *change* the files lovingly
>>>>> crafted by academics, even though the bid clearly spelled out that
>>>>> this was only format conversion and that the original files would
>>>>> also remain available.  Ah well.] In 2010 as part of a business as
>>>>> usual drive to migrate some of the OTA texts into TEI P5, my email
>>>>> archive shows that Sebastian started working on a new cocoa-to-tei
>>>>> conversion and took my XSLT as the starting point and added the regex
>>>>> and an extra passes to do it all in a single XSLT while also making
>>>>> it a bit more general.  I contributed some bits and pieces.  That is
>>>>> probably why it isn't as generalised as it could be.  But I think it
>>>>> serves better as an example than a generalised conversion.
>>>>>
>>>>> Although the OTA is now in the Bodleian Libraries, not here at IT
>>>>> Services, I doubt it will ever get rid of its Cocoa texts (even if it
>>>>> provides migrated versions of them). While it may be easier to just
>>>>> get rid of the conversion I would certainly be willing to give it a
>>>>> go in trying to fix it. (i.e. If you've made a github issue, feel
>>>>> free to assign to me.) As to why we should have and maintain legacy
>>>>> conversions like this, I would say that it is as an example for those
>>>>> approaching similar migration up-conversions.  I'm not saying that is
>>>>> a very good reason, but since it used to work I'm suspecting that
>>>>> making its output valid again wouldn't necessarily be too difficult.
>>>>>
>>>>> -James
>>>>>
>>>>> On 07/01/17 18:40, Martin Holmes wrote:
>>>>>> What I'm actually trying to do is understand the situation better,
>>>>>> and I'm getting there. This is what I think we've learned:
>>>>>>
>>>>>>  - Cocoa is not very amenable to a generic conversion process, since
>>>>>> its syntax and usage is extremely variable;
>>>>>>
>>>>>>  - Our current Cocoa conversion script (James will hopefully confirm
>>>>>> or refute this) was written specifically to convert certain OTA
>>>>>> texts, and could not be applied generically;
>>>>>>
>>>>>>  - In any case, that script is broken (it produces invalid TEI);
>>>>>>
>>>>>>  - There is a possible way forward in writing a conversion that
>>>>>> creates milestone elements, as suggested by Lou, but that would
>>>>>> still depend on knowledge of the actual syntax and special
>>>>>> characters used in any specific set of texts;
>>>>>>
>>>>>>  - There are still some Cocoa texts out there which have not yet
>>>>>> been converted to TEI.
>>>>>>
>>>>>> What I take from this is that it would probably make more sense to
>>>>>> work with those people such as Elizabeth who have Cocoa texts that
>>>>>> matter, and get those converted to TEI; meanwhile we could retire
>>>>>> the conversion that doesn't work, and remove it from the Stylesheets
>>>>>> repo. This is obviously a question for Council, though.
>>>>>>
>>>>>> Cheers,
>>>>>> Martin
>>>>>>
>>>>>>>
>>>>>>> cheers
>>>>>>> stuart
>>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>