[r-t] Central Council Methods Library

[Graham John]

On 29 May 2018 at 12:29, Don Morrison <dfm at ringing.org> wrote:

> However, I would like to suggest for the future a bit more warning to us, its consumers, of what is coming and when, whenever you do make significant changes.

Yes, I agree, but it was necessary given that the existing collections
had been removed with no message to say that they would be reinstated.

> - Tony’s old versions were typically updated at the end of each week. Do you anticipate holding to a similar update schedule, or will it be something different, in regularity, granularity, and/or absolute location in time?

At least weekly, but it could be more frequent, such as daily.

> - When deciding whether or not to download the latest XML from Tony’s old version I would use the HTTP ETag. That is, I’d send an HTTP HEAD request for the file, and compare the resulting ETag with that I had received from the last version I’d downloaded, and only proceed to actually download and install the new file if they differed. Will such a scheme continue to work correctly in the new regime?

I'm not familiar with ETags. However the site is served by GitHub, so
it may well have default support for them.

> - When unzipping CCCBR_methods.xml.zip it comes out with no permissions at all, not even readable by owner. Is there a reason for this, or is it some odd artifact of how you’re zipping it, and perhaps a minor bug?

This appears to be a bug with the zip api I have used. It is not a
problem for downloads to Windows, but I will look for a resolution for
Linux users.

> - From the year in the URL, and the “Version 1.0” in the <documentation>, it appears the XML schema is unchanged from that used in Tony’s old version. Is this correct? And, thus, am I correct in believing that for the XML stuff there are no changes in the format?

Yes, it is using the same schema. There will be subtle differences -
for example there is a difference in the split of methods into
methodsets. Also the method IDs are not those of Complib preceded by
'm' rather than an incrementing number (the benefit now being that
since they are unique it is easier to distinguish amendments from
deletions). Performance data is richer, as data is supplemented from
BellBoard, and a BellBoard performance ID prefixed by 'bb' has been
added to performances where they have been identified. There has also
been a slight change in the numbering of the more obscure leadhead
groups such that all Plain Bob leadheads can be represented, even
those with short courses (see
https://cccbr.github.io/method_ringing_framework/leadheadcodes.html).
Also Blocks are treated as a class of method rather than being
excluded from the format completely as non-method blocks. Finally the
file names are different.

There is not a spec for the Microsiril collection format as far as I
am aware. I have tried to reengineer them to match those generated by
Julian Morgan as far as possible, but I did find some anomalies in
those which I notified to him.

> - Are there any further changes, other than added or updated content, planned?

As some point, I will probably also extend the performance node tags
of the XML to allow the inclusion of other types of notable
performances such as firstTowerbellQuarter,
firstInclusionInHandbellQuarter, longLengthTowerbellPeal etc.

I have received some comments on the text file format, which I will
have a look at. The previous format appears to be a legacy of the
original paper collections, and much of what they provided is now much
better served by the Composition Library (or ringing.org) website, or
the XML data for serious developers. I had assumed that the main use
of text would be for a bit of casual downloading into spreadsheets or
word documents. I could provide pretty well anything, but would rather
we agreed on just one text format.

Graham