Yes, I meant oXygen's view of things. And I suppose if these things showed up as warnings (as I assume they're supposed to) or informational messages, then I wouldn't be so worried about #2 and #3. #2 is a bit of a head-scratcher. I'm mostly against using default values at all, but I've been working with someone else's ODD, who seems to be a fan of them. I see the argument that if an attribute is required, then giving it an automatically-supplied value is possibly unwise because you can end up with "invisible" required attributes. The message "It does not make sense..." is a little obtuse, however. A better message would explain why it might not be a good idea, rather than just saying, in effect "you're doing it wrong, dummy" :-). I guess if the exemplar is only meant for those directly customizing TEI, then #3 is justified. And I shouldn't be using it. Again, though, I think the message could be better. Telling people the @source is not in the recommended format doesn't really help if you don't tell them what that format *is*. Hugh On Wed, Oct 28, 2020 at 9:11 PM Bauman, Syd wrote:

Hi Hugh! Replies interspersed …

------------------------------

If I have bug reports, should I make GitHub issues for them?

I suppose so, in the TEI repo. But I like a bit of discussion here first, honestly.

1) @role="nonfatal" I think is not understood as a warning, and gets you the usual red underline/error presentation. I feel like warn and/or info might be better. Oxygen's supported role levels seem to be:

"warn" or "warning" "error" "fatal" "info" or "information"

Good point. Of course, when you say “is not understood” you mean “is not understood by oXygen”. The value of Schematron’s @role is not defined by ISO/IEC 19757-3:2016 (other than as a string or xs:NMTOKEN). But either oXygen used to understand "nonfatal", or at least someone told me it did, because (IIRC) the goal was to have things work nicely in oXygen. After all, a huge percentage of TEI users use oXygen. So I am all in favor of limiting our values to those recognized by oXygen. (And of complaining to SyncRO if we feel we really need another.)

2) default values for required attributes are flagged. I can sort of see the logic there, but they're not *really* the same thing.

Well, yes, you are right, they are not really the same thing. But it is something I was, until just now, quite confident we could all agree should not happen. That is, no <attDef> should have both @usage="req" and <defaultVal>. One or the other, else you are sowing the seeds of confusion. (Remember, the goal here is to help you *write* a customization, not to allow anything ODD allows.)

3) non-"tei:" schemes in @source are discouraged, but what if your source isn't a TEI release? I've got a couple of these, and I'd like to be able to put a URI in there without being yelled at.

Heh-heh. My first reactions were “then you should not be using this schema” and “too bad”, respectively. But thinking about it more, the definition of @source only says that the "tei:*" format is preferred when you are using a private URI scheme, not over regular URIs. Hmmm … what do others think? I lean towards thinking it is more important to catch "TEI:4.1.0" or "tei: 4.1.0" as errors than to allow full URIs. (Remember, the purpose here is to help someone write a TEI customization ODD; nothing more.) But I might be putting too much weight on it.

_______________________________________________ Tei-council mailing list Tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council