From: Martin B. <mjb...@li...> - 2003-11-07 15:38:48
|
--On 05 November 2003 19:02 +0000 Richard Smith <ri...@ex...> wrote: > A couple of points to make on method.xsd.txt: > > I think we decided that 'Differential' was for these purposes a class. > (It's not a class according to the Decisions.) I can't remember what we decided, to be honest. Since we now have the classification elsewhere, should the <classes> element just be the textual part which goes into the method name? Should it be blank for principles? >| 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.) Yes. > Can E and T be in lower case? (I think not.) I don't see why not, but don't really mind. I think our philosophy is that the XML standard should be as permissive as possible, but in our own database we can be more stringent on how we store it. > 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.) Yes. I don't see any need for the \b though - just {24} would do. >| <mc:ref collection="surprise-major">3738</mc:ref> > > How does this handle different editions of collections? Either they have different names, or else we have a "version" attribute. > 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. Yes, I think we probably ought to put anything which the MC officially support in the one namespace. > <pedantic> >| Little methods would have little="true" and Differential >| methods would have differential="True". > > It should be "true", not "True". > </pendantic> <pedantic> Error - opening tag `<pedantic>' closed by `</pendantic>'. </pedantic> Yes. > >| | <s:symmetry> >| | <!-- some elements describing symmetry --> >| | </s:symmetry> > > I think some classification of symmetry should be in the > base naemspace. Yes. > 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 agree that XLink is far from ideal, but at least philosophically it does what we want. XInclude would have the disadvantage that implementations would feel free to process them at parse time. In general, it's probably not worth tweaking the XML spec too much before the Methods Committee get back to me. They're bound to have various changes they want to make. >> - 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. I think having persistent IDs would be a good thing. The other stuff might also be good, but can wait. >> - 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. Excellent. For those that don't know, we've decided to release a core part of the class library (including the library-access classes) under the LGPL. This means that you *can* now use it in your own commercial programs if you like. A Perl interface would be dead easy. What other languages do people use for on-line applications? Did somebody mention writing a Java interface? I would suggest that any API be somthing like: - Turn the user's search criteria into a query string for the database; - Get the XML result; - For each <method> element in the result, create a native-language object containing a pointer to that element in the DOM tree; - Provide methods on the native-language object to retrieve different bits of information about the method. >> - 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. I'm not sure exactly who would use this, I must admit. OTOH it would be quite simple to provide. I have recently realised that it's probably enough to check that the first word is `SELECT', and then pass it to $dbh->prepare(); that will throw an error if there's any more than one statement in there. Martin -- Martin Bright Department of Mathematical Sciences, University of Liverpool |