Re: [Ringing-lib-discussion] Method database - getting there

[Richard S. <ri...@ex...>]

Martin Bright wrote:

> An
> XML Schema is in "method.xsd" on the CVS repository, and some text
> describing it in "method.xsd.txt".

A couple of points to make on method.xsd.txt:

| |   <name>Pudsey</name>
| |   <stage>8</stage>
| |   <classes>Surprise</classes>
| |   <title>Pudsey Surprise Major</title>
|
| These are self-explanatory.  [...]

I think we decided that 'Differential' was for these
purposes a class.  (It's not a class according to the
Decisions.)

| Place notation contains no whitespace.  Either x, X or - may be used for a
| cross change.  Dots may be put next to x, X or - if desired; [...]

Are external places optional?  (I think so.)  Can E and T be
in lower case?  (I think not.)  Did we want to include the
mechanism we discussed earlier in the year for specifying
bells on very high numbers -- e.g. \b{24}.  (I think this
would be useful.)

|     <mc:ref collection="surprise-major">3738</mc:ref>

How does this handle different editions of collections?
For example, Plain Minor methods are numbered P1 to P29 and
P1A (Why?) in the 5th edition of the CC Minor Collection,
but in the 6th edition they are numbered 1 to 99 (with no
simple correlation between numbers).

Do we feel it is the right decision to include rwref in the
base namespace, but defer collection ids to some other
namespace?  From the MCs point of view, this proposal is not
likely to be particularly useful without additional elements
for CC collection ids, classes and (probably) symmetry.
Given this, why not put them all in one namespace as this
will aid older, non-namespace aware XML implementations.

<pedantic>
| Little methods would have little="true" and Differential
| methods would have differential="True".

It should be "true", not "True".
</pendantic>

| |    <s:symmetry>
| |      <!-- some elements describing symmetry -->
| |    </s:symmetry>

I think some classification of symmetry should be in the
base naemspace.

| |     <performance xlink:arcrole=
| |                          "http://cccbr.org.uk/relations/record-length"
| |                  xlink:type="simple"
| |                  xlink:href="http://www.peals.net/database.xml#395"/>
|
| This is a pointer to some other place where the details of a performance
| may be found.  It is very important to support such indirection, so that the
| method format would be able to interact with an XML peal database.

And in a case where we use xlink to reference a remote
performace, do we put any restrictions on what the href must
point to?  For example, must it link to element of type
performaceType?

Personally, I'm still of the opinion that XLink is far from
ideal for this purpose.  (Actually, I think it's far from
ideal for *any* purpose.)  Might XInclude be a better
technology?


> I think that we should make
> sure that the database supports whatever they finally come up with; in the
> meantime we can support our draft.

Agreed.


> So, what now?
>
> - Get scripts in place to keep the database up to date.

IIRC, I got Don Morrison's script doing a lot of this.
Persistence of reference numbers was one main thing left.
Do we still need that to work?  Performances were another
thing.  (Didn't we have some clever plan about populating
the Location table with stuff from Felstead and/or Dove?)
Oh, and then there's Doubles variations.


> - Develop a few client-side interfaces so that programmers will use our
> database in their programs.

The Ringing Class Library has basic support for both the XML
format and fetching from methods.ringing.org.  I'll have
another look at this later in the week.

> - Think about the `complicated' interface which will be a safe way for
> clients to execute almost arbitrary SQL statements on the database.

Do we still think this will be useful?  Providing a script
to suck *all* the data out and into a local database might
be a better solution.


Anyway, time for the fireworks.

Richard