Adding listOrg to event

[trishaoconnor]

Creating this PR for adding listOrg to event.

[martindholmes]

@trishaoconnor The test failure seems to be caused by an ambiguous content model in the XML Schema (xsd) generated from the RNG. The exact error (per Xerces) is:

"http:// www.tei-c.org/ ns/1.0":org and "http:// www.tei-c.org/ns/1.0":org (or elements from their substitution group) violate "Unique Particle Attribution". During validation against this schema, ambiguity would be created for those two particles.

This is caused because there are two different ways an <org> element can get into an <event> in the spec as presented in this PR. The first is through model.personLike, of which <org> is a member; and the other is through the literal mention of <org> in your added clause. When the same element can appear through two different routes, XSD validators don't know what path to take when validating, so they reject the schema.

I think the simplest solution might be to replace your clause with a simple <elementRef> for <listOrg> alone, but that would allow something which you presumably wanted to prevent: having both <org> and <listOrg> as children of the same <event>. That could be constrained by Schematron, but there is surely a more elegant way to do it.

[trishaoconnor]

Thank you for clarifying the error, @martindholmes. In my initial attempt, I had used a simple `<elementRef key="listOrg"/>` and it passed the tests without issue. That explains why there was no error then. I will revert to the simple solution for the time being but will add the schematron constraint too.

[jamescummings]

Thinking about whether you might want <listOrg> and <org> inside the same <event> (or similar listX and X inside Y situations), the only reason that occurs to me is that if you want to encode that the event was organised by org1 and group-of-orgs2 then you might want both. However, if one thinks about this, then that is why listOrg can self-nest. So you'd have a listOrg with an org (for org1) and as a sibling to that a nested listOrg (for group-of-orgs2). So yeah, a schematron constraint saying you can only have a single <org> or one-or-more <listOrg> would make sense to me.