Restrict location types for functional infrastructure elements

The EntityIS type extends RTM_LocatedNetEntity, which in turn defines three optional and repeatable location elements: spotLocation, linearLocation and areaLocation. There is no syntactical restrictions on which type of location that can be used for each type of infrastructure entity. For some entities, multiple location types can make sense. As an example, a switch may have a spotLocation for the point where the switch creates a branch in the topology and an areaLocation for the physical extent of the switch. So far, the use of different location types has not been regulated by the standard.

The ETCS working group proposed two semantic constraints to only allow spotLocations on IS:baliseGroup (IS:021) and IS:balise (IS:022). This raises the question if we should constrain location types also for other infrastructure entities. It also deviates from the defined purpose of semantic constraints in railML: to restrict the allowed values of one property depending on the values of other properties. Defining that a certain element only has certain subelements is normally defined in the syntax.

There are multiple ways forward:

1. Syntactically constrain available location types per entity. This would require a change in RTM (create alternatives to RTM_LocatedNetEntity), or its use in railML (inherit RTM_NetEntity instead of RTM_LocatedNetEntity and add fitting RTM_*Locations to the entity types).
2. Add semantic constraints on more (most?) infrastructure entities.
3. Add a best practice per entity type, documenting how to interpret and use the different location types per entity type.
4. Do nothing. Leave interpretation as an exercise for the reader.