drop the last sentence ("recommendation on atomic values") of 18.5

[bansp]

There is a sentence in chapter 18, just before section 18.6, that says:

Although in principle the @fVal attribute could point to any kind of feature value, its use is not recommended for simple atomic values.

The statement illustrates a fragment of markup that contains, a.o.:

   <f name="pos" fVal="#V"/>
   <f name="val" fVal="#TRNS"/>

I think the statement above is wrong at many levels:

• Most generally, it goes over the top wrt the TEI's being a toolkit for customizations -- a decision to point at atomic vs. non-atomic values must be the modeller's, not the TEI's. In relation to that, one could rightfully ask, "not recommended by whom?" and all issues of authority and competency would then be invoked.
• and it's scary how many issues are hiding here: "'atomic' at what level?", one could ask. There have been approaches analysing the standard parts of speech, say, N V A (P) into component values, but even if that is done, it's implicit, no one is going (ok: very few are going) to dissect a N into component features in a corpus document -- corpora don't care about such distinctions. Further, corpora don't usually use N,V,A,P -- the actual symbols are complex, but again, their complexity (sometimes involving more than one grammatical component) is implicit at the level of the corpus. And why should that implicit complexity be treated differently from explicit (marked-up) complexity?
• another issue is that the level of complexity on the other side of the reference can be variable, and that factors other than complexity of the referenced object come into play in defining annotations -- sometimes it's also a matter of uniformity or even of economy of representation, often even simply of the size of the resulting document;
• finally, many existing resources that do use @fVal explicitly don't care about that mysterious recommendation, and that is a practical argument for dropping it.

I didn't dare silently remove the sentence when modifying the chapter for issue #2227 but I would happily add that change to the current PR. But it can also wait, because chapter 18 begs for some editorial love irrespective of att.datcat.

[lb42]

This sentence was added between P4 and P5, when the section on feature values was extensively revised and simplified by members of the ISO TC37 workgroup chaired by Kiyong Lee. I believe the intention was to express a preference between two methods of representing a feature whose value was atomic (i.e. expressible using only the atomic constructs defined by the FS recommendations -- <string>, <symbol> etc. ). In earlier versions, this could only be done by embedding the appropriate element within an <f>; later versions added the possibility of doing so indirectly by defining such a feature and then referencing this via the @fval attribute. I think the sentence is intended to recommend against the latter method in the interest of reducing syntactic complexity or verbosity. But your point about this being a choice better left to the encoder is a good one. I have no skin in this particular game (whatever that means) so would not object to this sentence's disappearance.

[bansp]

Hah, thanks Lou -- that explains a lot. But if the sentence was meant to recommend doing

<f name="val" fVal="#TRNS"/>

over

<f name="val"><symbol>TRNS</symbol></f>

(which is something I can sympathize with, especially in the light of the CS-minded people's criticism concerning the separation and placement of datatype constraints/information from/versus the actual data item), then, it seems to fail to communicate the intended message :-) But then we're down to the argument concerning the encoder's choice of their favourite tools. I wouldn't mind phrasing that implicitly, for example by making the more concise examples more prominent than the datatype-around-value ones. But it seems to me that that should be the limit of the mindplay.

[lb42]

Well, no, I think the intent was exactly the opposite!

[bansp]

I've searched for "atomic value" across this chapter now and I see that the sentence is not incoherent, but I'd still say that it's too much as a recommendation. In the fragment

the simplest such complex value is represented by supplying an fs element as the content of an f element, or (equivalently) by supplying the identifier of an fs element as the value for the fVal attribute on the f element

This seems where @fVal is mentioned as an alternative to using <fs> as the value directly. But that would take me back to the beginning of this issue, and most if not all the points would still be applicable, I think. Maybe complemented by saying that, OK, that may have been the intention behind introducing @fVal, but the actual use appears to have outgrown the intended range of applications and it is not practical to recommend anything other than the object on the other side being a suitable feature value of any complexity. Plus, the original drive from SC4, as far as I can recreate it in my mind (and it's a hazy memory, let me stress), did not intend to put any focus on the dichotomy between complex and simple among the objects pointed at. I'm guessing that the main focus was on aligning ch. 18 with the ISO LAF (and GrAF) where an <f> can have content whose data type is determined/constrained independently.

Incidentally, this is yet another case where this chapter made me wish for some kind of floating or just generated list of definitions in use in the given document, the way I sketched it in #2358 . That would be a very nice enhancement, not only for standardization-related documents.