setting should contain placeName

[dariok]

Currently, setting may contain orgName and persName as well as the general name – but not placeName. All examples in the GL use name for the place.
I think it would be more consistent if placeName were allowed here.

[sydb]

1. I agree. (But remember that <placeName> is not the same as <locale>, which already goes in <setting>.)
2. The devil is in the details: we need to worry about whether the content model of <setting> should be changed to use model.nameLike instead of model.nameLike.agent, OR if <placeName> should be added to model.settingPart.

[sydb]

@dariok — Having looked at this a little more carefully, we (a Council sub-group) are wondering what is the use case for which <locale> is insufficient, and you would want a <placeName> inside <setting>?

[ebeshero]

Full Council notes that there's a good reason to put <placeName> in <setting>, to be used alongside <locale>, which is meant to indicate a sub-place, a part of a place. Assigning to @sydb , and this is green to implement.

[sydb]

Council is planning on adding <placeName> to model.settingPart and changing the example on the tagdoc to use <placeName> for NYC, rather than <name>.

[ebeshero]

@sydb Are you good for adding this before the release? Or want someone else to take this on?

[sydb]

Fixed (pending Mr. Jenkins’ approval) at 04d4b37. The concern, of course, is whether or not any ambiguous content models or detest change problems have been introduced. I checked briefly for the former, and I am pretty confident there are none.

Thanks for the reminder, @ebeshero !