n="added gathering" in XML examples

[gerritbruening]

See https://github.com/search?q=org%3ATEIC+%22added+gathering%22&type=Code.

@jamescummings thinks that this is only a typo for n="added_gathering" (with an underscore to make it one attribute value).
But do you really think that added gathering is a good value for @n?

[jamescummings]

Definitely a typo. Underscore or camel case addedGathering if keeping that term.

Whether it is a gathering or not one can't really tell from that markup.

[gerritbruening]

Maybe "quire" would be the more common term. But given that a quire was added here, what I had taken for granted: Again, would you store this information in @n?

[jamescummings]

I think gathering and quire are both used depending on school of description (and print vs mss) so that bothers me less. I mean we have gb as gathering beginning in the tei as well which is at least consistency. But the free text in the n attribute is definitely something I'd consider a bug even if others do not. Must do a check for all @n attributes and check!

[gerritbruening]

I personally don't like these blanks either, but here I read:

single token which may however contain punctuation characters, whitespace

Anyway, is "added gathering" a "number (or other label)"? Maybe I just don't understand what "label" is for in this context. Please forgive my stubbornness.

[jamescummings]

Yes. I think that is also not good. I would have @n be an unordered series of whitespace-separated tokens (like @rend)

[hcayless]

I don't see any problem here. @n's datatype is teidata.text, which permits punctuation and whitespace. @rend's datatype is 1-∞ of teidata.word. These are different for perfectly sensible reasons.

[sydb]

And, for that matter, "added gathering" is a perfectly reasonable value for 1-∞ of teidata.word. (@jamescummings wants teidata.word to be teidata.token, but it was not intended that way.)

[jamescummings]

Sure, I'd feel better if that was the case but accept it is not. I have a distinct memory of council several years ago deciding at some point that while we wouldn't change the datatype we would stop exemplifying using spaces in @n. Perhaps I am mistaken. A quick (a probably inaccurate) ballpark search of use of @n with spaces in it (not including things like our guidelines specGrp's) in the Guidelines prose (not spec files) shows that only 3.5% of uses have spaces. Namely:

CC-LanguageCorpora.xml:<egXML xmlns="http://www.tei-c.org/ns/Examples"><textDesc n="Informal domestic conversation">
CO-CoreElements.xml:   <divGen n="Index Nominum" type="INDEX-NAMES"/>
CO-CoreElements.xml:   <divGen n="Index Loci" type="INDEX-PLACES"/>
CO-CoreElements.xml:  <div2 n="Amores 1" type="book"><!-- ... --></div2>
CO-CoreElements.xml:  <div2 n="Amores 2" type="book">
CO-CoreElements.xml:    <div3 n="Amores 2.1" type="poem"><!-- ... --></div3>
CO-CoreElements.xml:    <div3 n="Amores 2.10" type="poem">
CO-CoreElements.xml:      <l n="Amores 2.10.7"> ... </l>
FS-FeatureStructures.xml:<egXML xmlns="http://www.tei-c.org/ns/Examples" source="#UND"><fLib n="phonological features">
FS-FeatureStructures.xml:<egXML xmlns="http://www.tei-c.org/ns/Examples" source="#UND"><fvLib xml:id="fsl1" n="phonological segment definitions">
FS-FeatureStructures.xml:<egXML xmlns="http://www.tei-c.org/ns/Examples" source="#UND"><fvLib n="Major category definitions">
FS-FeatureStructures.xml:<egXML xmlns="http://www.tei-c.org/ns/Examples" source="#UND"><fLib n="categorial features">
FS-FeatureStructures.xml:<egXML xmlns="http://www.tei-c.org/ns/Examples" source="#UND"><fvLib xml:id="C6" n="Claws 6 tags">
FS-FeatureStructures.xml:  <fvLib xml:id="FSL1" n="phonological segment definitions">
FT-TablesFormulaeGraphics.xml:        <figure n="Ex. 3">
PH-PrimarySources.xml:                     <addSpan n="added gathering" hand="#heol" spanTo="#p025"/>

Generally I'm of the opinion where someone wants a truly textual label then really they should be using <label> or similar. But, as you know, I'm resistant to free text in attributes.

[emylonas]

Fixed in ca4994b by adding dash to eliminate space