Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

set of presets is ridiculous #127

Open
sydb opened this issue Mar 17, 2021 · 3 comments
Open

set of presets is ridiculous #127

sydb opened this issue Mar 17, 2021 · 3 comments
Assignees

Comments

@sydb
Copy link
Member

sydb commented Mar 17, 2021

[BTW, I take at least partial blame for the situation as it is. IIRC, I was the one who recommended the current list of presets. I am allowed to call myself ridiculous. :-)]

If I start with the jTEI preset and change the Author field on the 1st page to “Syd”, the ODD file I download has

      <titleStmt>
        <title>Test</title>
        <author xml:id="RvdB">Syd</author>
        <author xml:id="MDH"><name>Martin Holmes</name> <email>[email protected]</email></author>
      </titleStmt>

In one sense this is just a bug — we haven’t thought through what should happen when there is an existing <author> element and the user fills out the Author field.

But I think it is indicative of a much larger problem. The “preset” starting points are exemplar customizations that include lots of stuff that would typically only get in the way of generating a TEI schema. For example, if I start with tei_all, my downloaded ODD file asserts that it is published by the TEI Consortium, which is unlikely to be the case; and it not only contains an <availability> that might make no sense for my ODD, it contains an <availability> that makes no internal sense — it says it is "free" and yet only available under certain licenses. It also. (That last is probably a bug that needs be reported in the TEI repository.)

I am not sure what the right solution is, but my instinct is that rather than presets based on the exemplar ODDs, we should have only 2 presets: “build up” and “trim down”, which would have just the specification bits, not the metadata and prose. If someone really wants to start with jTEI, we can provide instructions on how to get it, and they can use UPLOAD ODD instead.

There are variations on this theme that should be considered, too. Like leaving the presets as they are and adding the two suggestions, above, as “recommended starting points”. Or that with only those 2 presets quite a bit more of the metadata (like publisher, license, edition, etc.) should be required.

@raffazizzi
Copy link
Contributor

I think it would be too bad to lose the presets as a starting point; I have often had students start from SimplePrint. We also shouldn't avoid loading the existing metadata only in some cases. It's up to the user to clean up license and availability data IMO.

BUT, I could make sure to add an <application> with information about Roma making changes on the original. Would that work?

@raffazizzi raffazizzi self-assigned this Mar 9, 2023
@raffazizzi raffazizzi added this to the v1.0.0 milestone Mar 9, 2023
@raffazizzi
Copy link
Contributor

Lol sorry @sydb just saw your other issue: #128

Would you say that solving that one would sufficiently address this one?

@raffazizzi raffazizzi added to do awaiting response I answered or addressed the issue and requested feedback and removed enhancement to do labels Mar 11, 2023
@sydb
Copy link
Member Author

sydb commented Mar 12, 2023

Well, no, I don’t think so. I think #128 (which I see you have already implemented, @raffazizzi) is important, and does reduce the importance of this ticket. But it does not change the fact that starting with one of our “sample” exemplar ODDs causes problems, or that starting with a “template” exemplar ODD is at best closet to useless and at worst misleading.
(For the distinction between those two types of exemplars see jTEI article paragraphs 26 & 27.)
However, especially since the same problem stares us in the face from Roma Classic, I do not think this is a particularly high priority ticket. I think we should fix this situation, or at least make it better. (And yes, <appInfo> is a step in the right direction, but is insufficiently “better”.) But I do not think we have to rush or hold up publication or promulgation of new Roma because of this continuing problem.

@sydb sydb added enhancement and removed awaiting response I answered or addressed the issue and requested feedback labels Mar 12, 2023
@raffazizzi raffazizzi removed this from the v1.0.0 milestone Mar 13, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants