Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#196 TEI Changes since ODD last loaded

RED
closed-wont-fix
5
2010-09-23
2009-08-10
James Cummings
No

It would be a handy feature for ROMA or ROMA-NG for it to look at the date the ODD was last saved, and output a list of new/changed elements/classes/modules that had been changed since the last time the ODD was saved.

use-case: A project or community has an ODD where they have tightly constrained the TEI. As good TEI users they want to keep it in step with developments in the TEI, and so regenerate their schemas when a new version is out. Suddenly they have a bunch of elements / attributes they don't want and have to go track them down.

implementation: This could be implemented as a webservice: You give it a date and you get back a list in some format with references to those bits which have changed.

backend-implications: This would mean that any time a substantive change (addition or modification of content model say) was made to an elementSpec or similar, the person editing it would have to update a date-related attribute which would have to be added to *Spec. Implementing the webservice is a search through these attributes for any which are after the date provided. Existing *specs could be primed with a last revision date from subversion, somehow, I'm betting.

Side benefits: It would also give a list of 'things changed since last maintenance release'. Granted, not one with descriptions of the nature of the change, but it would be a help. Reference pages could also include a 'This element was last edited at: @when' type phrase.

-James

Discussion

  • I don't think I can remotely see when or how to implement this, I am afraid. I'ts a genuine situation, of course.

     
  • Lou Burnard
    Lou Burnard
    2009-11-03

    • milestone: --> RED
     
  • BODARD Gabriel
    BODARD Gabriel
    2010-02-17

    I can see that this isn't something high on Sebastian's radar, but this would also help to address the problem I had recently with the EpiDoc ODD constraining an attribute more tightly than TEI default, and that attribute having changed class between two releases[*], leading to an (easily fixed but invisible, to me) invalid rng being generated from an unchanged ODD.

    [* @cert having moved from model.editLike to model.responsibility]

     
  • But how can I tell from your ODD file when you last changed it? This whole subject is full of complex issues....

    But I agree that one could deliver a more intelligent "diff" between TEI versions to
    give a human-readable report.

     
  • James Cummings
    James Cummings
    2010-04-28

    1) ODD file should contain a reference to the version of the TEI it was created against.
    2) TEI Vault should eventually contain sources of that release
    3) To implement the steps we need to do:
    a) generate RNG of original version from ODD
    b) generate RNG of current version from ODD
    c) Intelligent RNG-aware XML Diff between two them.

    This seems in the realms of possibility... 1) is fairly trivial, 2) is something we should be doing anyway, 3) Is more difficult but seems much more likely that someone might have already done a RNG-RNG Diff.

    -James

     
  • Lou Burnard
    Lou Burnard
    2010-08-05

    As of release 1,7, an ODD file can reference an explicit version of the TEI via the @source attribute. The files generated by Roma and other users of the odd2odd stylesheet now include a reference to the version against which they were generated as well. With the "new style" ODD system it is possible to define an ODD by inclusion rather than exclusion, thus mitigating considerably the concerns raised in this ticket. We have no resources to add further major new facilities to Roma. I would like to close this ticket.

     
  • Lou Burnard
    Lou Burnard
    2010-09-13

    • status: open --> open-wont-fix
     
  • Lou Burnard
    Lou Burnard
    2010-09-13

    Proposal is to close this ticket for reasons given in my comment of 5 aug 10

     
  • Kevin Hawkins
    Kevin Hawkins
    2010-09-13

    I'd like to hear from James to see whether he feels release 1.7 sufficiently handles his needs.

     
  • James Cummings
    James Cummings
    2010-09-14

    I agree that as of release 1.7.0 ODDs have the @source attribute and this can point to a version of the TEI in the vault. This DOES NOT really answer the underlying problem of this ticket, but does make it go away in most instances. By that I mean that if I'm pointing to version 1.3.0 and think "maybe I should update my ODD and point at version 1.8.0" I still have no way, as a general user, to know what the changes are between 1.3.0 with those elements included by my ODD and 1.8.0. Pointing to a specific version means that I'm no longer surprised by the sudden inclusion of new elements. However, what I think the changes in 1.7.0 have done is enable the possibility of building something which does express differences between your ODD and current TEI similarly customised. What we need is some enterprising person to write a web service like thing which says "Ah, your ODD points to version 1.3.0 and you include only these elements/modules, if you changed this to $current you would get these changes: [list of changes]". If someone creates such a service, I think the TEI-C should host it.

    I think the TEI has now enabled the possibility of doing this. Where it wasn't possible before (because I didn't know what version of the TEI you used, or have access to other versions of it easily) it is now possible.

    I accept that it is arguably not the TEI's job to create something to do this service. However I would suggest that now that it possible we should encourage as good practice to point to the specific version of the TEI in the vault that an ODD is using.

    I'm happy for this ticket to be not-fixed because it may not be the TEI's job to create this but instead create the possibility of doing so, which it now has.

    -James

     
  • Lou Burnard
    Lou Burnard
    2010-09-23

    • status: open-wont-fix --> closed-wont-fix
     
  • Lou Burnard
    Lou Burnard
    2010-09-23

    Closed after further review by council