orderby enum should not contain complex types OR should project sub-properties that are not complex types

for GET /me/calendar/events we currently project an enum value of start and start desc.
This ends up failing on the service because the start property is a complex type and cannot be used for ordering.
The conversion library should either:

1. not project properties that are complex/entity types
2. project sub properties of the complex/entity types which are themselves scalar types (e.g. start/dateTime desc )

If we go with 2, this brings a couple of questions:

1. how many levels of depths should this support?
2. what's going to happen for consumers using that metadata to project enums / union types of constants which all of a sudden will see a / character appear, which is reserved in most programing languages?

This also impacts graph explorer as we're suggesting customers things that cannot work.

Commencez par retracer comment les métadonnées de GET /me/calendar/events produisent l’énumération orderby et où les propriétés complexes ou d’entité sont classées. Comparez les deux comportements proposés, notamment la profondeur d’imbrication et la gestion des barres obliques pour les constantes générées. Le travail est terminé lorsque le projet dispose d’une règle décidée et testée qui évite de suggérer des valeurs orderby que le service ne peut pas utiliser.