The simplePrint ODD needs to be rewritten

[martindholmes]

The simplePrint ODD file consists of a sequence of direct element references. This is a bit mad, and causes problems when (as recently happened) an attribute class is moved from one module to another. It should be rewritten using moduleRef elements with @include.

[lb42]

I find this comment both offensive and inaccurate. The TEI Simple ODD contains a mixture of moduleRef and elementRef elements. It is not mad to use elementRef when, as was the case here, and is often the case (e.,g. when chaining ODDs) a number of basic decisions have been made -- corresponding with a choice of modules -- but the fine tuning is likely to be iterative and at the element level. It's much easier to add and remove individual elementRefs than it is to fiddle around with long attribute values., It's also a pain having to remember which module an element belongs to -- especially since the ODD processor won't tell you if you guess wrong. You don't tell us what problems you're thinking of, but moving attribute classes from one module to another happens vanishingly rarely. And moving anything from one module to another is likely to have repercussions no matter what style of ODD you are writing.

[sydb]

While I don’t think the original comment is at all offfensive, I agree with @lb42 on this one. It is perfectly reasonable to write an ODD using lots of <elementRef>s, and it’s good that we have an exemplar that does that, precisely so we get a heads-up in those rare cases when it does cause a problem. (However, we need to examine why we didn’t get that heads-up before release day.)-:

Although our one and only ODD processor will not tell you if you guess wrong, the tei_customization schema will. :-)

[martindholmes]

@lb42 I think there's a bit of a push to move attribute classes out of the tei module into modules where they're more closely related, presumably in order to reduce the number of attributes that end up in a schema which is intended to be fairly simple.

I think it's a bit mad because it makes the schema vulnerable to exactly this issue. There's no real difference in complexity with the two approaches, but using moduleRef/@include is more terse. I disagree that it's easier to edit the one with a long list of elementRefs; Control + F will find you any element you want in either case.

And "offensive"? Seriously? I think that word does not mean what you think it means. :-)

[lb42]

I used the word "offensive" because I felt offended at the implication that my way of writing ODDs was "mad". Call me touchy and move on, as you wish. But the point remains that the use of elementRef in this way is perfectly legitimate. It might not suit your personal way of working, but it suits others just fine, for the reasons I have given.

[duncdrum]

I have no opinion on the sanity of either solution, but since changes to simplePrint might impact tei-publisher in a big way i m tagging @tuurma

[martindholmes]

@duncdrum I don't think it should affect tei-publisher because we're not considering changing the schema; just the structure of the ODD that gives rise to it. That said, @sydb 's point that it could serve not only as an official customization but also as a canary to warn us if changes to processing have bad effects on ODDs written this way is a good one. If that's to be one of its purposes, then we need a thorough instance document that gets validated as part of the build process.

@lb42 Do you write all your ODDs this way?

[sydb]

Would it make sense to have a tei_not_quite_all ODD in the TEI Test/ directory that includes the "tei" module, and then has 573 <elementRef> elements?

Just thinking out loud. (And too tired to think clearly. :-)

[martindholmes]

If it goes along with an instance document that uses all 573 elements and the attributes, that would work fine, I think.

[jamescummings]

While I also think it is sometimes unsafe for inexperienced users to write ODDs where they are mostly by elementRef rather than inclusion from the moduleRef, this is because they usually don't know about the underlying class system. There are perfectly good reasons to do it this way, but I'd agree that TEI simplePrint takes it to an extreme.

With an ODD and Test file, that is fine and all, but sounds like a maintenance headache. Is there a way to generate a test odd and instance file so it is always up-to-date with the possibilities of TEI? (I'd have said grabbing examples from the spec files, but we famously do not exemplify use of all attributes, etc.) I'm not sure doing what I'm thinking here is possible, so then every time we changed an attribute or element we'd have to also go change this test odd and instance file?

[tuurma]

This thread somehow escaped my attention before. I don't have an opinion about best practices for ODD writing with the goal of producing a schema out of it, but since introduction of TEI Processing Model, ODD does have one more function, namely to specify processing via <model>s. The only place where you can do so is in an <elementSpec>. Therefore it's not only not mad but also the only possible way for teiSimplePrint ODD to be written.

[ebeshero]

This does not seem to be a release blocker now that dev branch is building again, so I'm going to just remove that and the 3.6.0 milestone.

[tuurma]

Btw, I remember we discussed moving model specifications out of schemaSpec altogether which makes perfect sense to me. Then I'd be happy to leave others to form best practice recommendations for ODD writing.

[lb42]

Moving the model specification out of schemaSpec entirely sounds a bit strange: where would you put them? But in any case it's not what this ticket started off proposing. In fact I cannot see what this ticket proposes, concretely.

[tuurma]

This was the initial idea, I think

It should be rewritten using moduleRef elements with @include

[lb42]

Ok, it's probably a matter of style and authoring preferences. I found the elementRef method much easier when decisions about which elements were to be kept were changing all the time. Since it's not broken, I really can't see any point in " fixing " it.

[tuurma]

As I said before, currently it's the only way to write an ODD including processing models, which teiSimplePrint does, so unless @martindholmes strongly objects I suggest to close this ticket.

[lb42]

I am not sure what the "it" you're referring to is. You can add processing models to an ODD written in either style, surely? But I am certainly in favour of closing this ticket!