#152 ODD should customize ODD

GREEN
closed
5
2010-05-09
2008-11-16
Syd Bauman
No

Summary: an ODD customization file needs to be able to say "I am a customization of that customization" as opposed to a customization of the whole TEI.

Currently a TEI customization is written as an ODD file that works by loading modules and obtaining information about TEI classes, etc., from a copy of the TEI source. The set of specifications from the specified modules in the TEI source are established, and requests to add, delete, replace, or change elements, classes, etc. are made against that set of specifications.
E.g., by default the commandline roma.sh uses the sources obtainable through http://tei.oucs.ox.ac.uk/Query/ (to find out which actual version of the TEI sources that server is using, see http://tei.oucs.ox.ac.uk/Query/getversion.xq\). This can be over-ridden to use any other TEI XQuery server with the --teiserver switch, or to use a local copy of the source files using the --localsource switch.
Thus we say that a customization is "built against" the TEI source. But in order for ODD to properly represent the delta from one encoding scheme to another, and thus gain the advantages of so doing, an ODD customization must be able to be built against another ODD customization, rather than against the TEI sources.
A limited version of this can already be accomplished. One can specify as the local source using the --localsource switch the "compiled ODD" file that was created by a previous execution of roma.sh that had the --compile or --debug switch specified. But this is unsatisfactory for several reasons:
1) It is not descriptive, has no abstraction
2) An ODD itself does not formally indicate against which it should be built
3) Customized attribute classes cannot be customized (as they are no longer first-class objects in the compiled ODD)
4) The compiled ODD must reside on the local machine
5) This is very hard for ordinary users to accomplish (although a front-end might alleviate that)
So I suggest TEI needs a mechanism for a <schemaSpec> to specify that against which it should be built. This should likely take the form of an attribute to <schemaSpec>, perhaps customizationOf=, which points (probably via URI, but perhaps by co-reference?) to an ODD customization file. If this optional attribute were not specified, the default would be to build against the usual TEI source, of course.

Discussion

  • James Cummings
    James Cummings
    2008-11-20

    My fears with this is it might encourage fragmentation and dispersal of version specification. By that I mean we get an increasing number of specification whose relation back to the TEI is much harder to trace. MyODD version 1.0 is a customisation of WibbleODD version 1.2 which is a customisation of TEI4Dummies version 0.85. Each of these customsations moves on separately with different version numbering systems, and are no longer available, it becomes increasingly difficult to know what version of the TEI they were originally built against. Equally it has to be easily possible to say that it wasn't built against any version of the TEI.

    I'm not against this as an idea... as you know I like the idea of being able to do weird things with ODD (e.g. embedding in encodingDesc of document instances, schematron, embedding crosswalk information to other formats in ODD, etc.)... I'd just want to make sure that maybe we record for each iteration of customisation the information in the ODD somehow. So I can know that TEI version P5 1.5.8 was used to create TEI4Dummies 0.85 which was used to create wibbleODD version 1.2 from which I made myODD 1.0. So a requirement of customisation then becomes the embedding of any previous customisation version numbering? Does that make any sense?

    Equally is it easy for myODD v.1.0 to revert something back to the way one of the other ODDs, or the TEI, does it... but not quite sure how that would be accomplished.

    Simiarly, for any *Spec should it also be possible also to include the definition of that *Spec from a remote location? And override only certain parts (like the <desc>)? I noticed that a lot of times we have duplicate attributes in the TEI that aren't all in an attribute class it is to give very minor differences of <desc>.

    -James

     
  • James Cummings
    James Cummings
    2008-11-20

    • assigned_to: nobody --> rahtz
     
  • Some progress has been made towards this goal,
    as attribute classses are no longer exploded into
    separate attributes in the compiled ODD. However,
    there is much more to do to get this working underneath.
    Once I am confident that it works, I'd like to return
    to the documentation and support of it, using perhaps
    a new attribute on schemasSpec as you suggest. This will also
    be discussed at the next meeting of the TEI Council.

     
  • Lou Burnard
    Lou Burnard
    2009-11-03

    • milestone: --> 871209
     
  • Lou Burnard
    Lou Burnard
    2010-05-06

    • milestone: 871209 --> GREEN
     
  • Lou Burnard
    Lou Burnard
    2010-05-06

    The proposal before Council, which seemed to meet with approval, was that the new @source attribute on <schemaSpec> or <moduleref> could be used to point to an existing ODD (or set of declarations) . Exact details of how this works in the case where the indicated ODD includes modifications are to be determined in implementation.

     
  • Lou Burnard
    Lou Burnard
    2010-05-09

    Added new attribute class att.readFrom, delivering attribute @source, members <schemaSpec>, <moduleRef> at rev 7479

    TD still needs major rewrite.

     
  • Lou Burnard
    Lou Burnard
    2010-05-09

    • status: open --> closed