author, persName, placeName, orgName, country, settlement: schematron rule to ensure certain instances of author have @key

[mjhawkins]

All these items have the similar triggers applied to them on sch:rule's context attribute and similar constraints on the value of their key attribute. The only difference is the name of the element in question in the rule (i.e. author, persName, etc). It's probably best to debate them all at once since I believe they all belong in MC.

There are two separate issues with the changes to this element:

1. The intention that author elements in certain contexts - namely ancestor::msItem and ancestor::fileDesc//idno[@type='catalogue'] = 'Western' - must have key atribute
2. key attribute, if required, must have the format person_\d+ (or place_id if the name-like element refers to a place)

The regex on the assertion (person\d+ or place\d+) is too lax. It would match:

• person_1235 (intended match)
• place_1234 (indended match)
• a_person_1234 (not intended)
• person_1234_and_something_else_besides (not intended).
• a_place_12_some_more_random_stuff (not intended)

^person_\d+$ would likely work better.

[mjhawkins]

Warning in GS for absence of key - but no constraints on contents.

Move current rules to MC and make warnings not errors.

[mjhawkins]

Right now, schematron only complains when the naming element occurs

• within an msItem (for author), origin (settlement) or msDesc (all other naming elements).
• and is in a file that has ancestor::fileDesc//idno[@type='catalogue'] = 'Western'.

Do we want to keep one or both of these constraints?

That is, do we want the general schema only to complain

• when @key is missing from a naming element in msItem?

or

• when it occurs within an msItem and the file also has fileDesc//idno[@type='catalogue'] = 'Western'

or

• do we want it to complain on ever naming element (persName), etc, regardless of where it appears?