Refactor schema/model classes to improve construction and validation usability, and access performance

[chrisspre]

The model classes are well designed to separate the consumption (via the IEdmXYZ interfaces) and the classed to construct a model.
But there are a few problems

• we have two implementations of concrete classes for almost all IEdmXYZ interfaces (e.g. IEdmComplexType via CsdlSemanticsComplexTypeDefinition , EdmComplexType )
• manual construction of models is quite different code compared to reading from CSDL
• quite easy to construct invalid models
• models read from file can not be modified
• we spend quite a bit of time to improve model querying/navigation
• the "FindXYZ" methods (like FindProperty on IEdmComplexType) are designed to work on valid models but are also implemented on invalid models (see the case insensitive issue a while ago)

I am proposing to restructure this on a high level.

• a hierarchy of classes that can be used to easily construct a model
  • the same classes are used to construct the model read from CSDL
  • model elements can be annotated with an abstract location (abstracted from CSDL file location)
• a step that builds a read only model. During this step,
  • validation will happen
  • users can specify the level of conformance to the standard (e.g. case sensitivity)
  • users can use/inject standard schemas and vocabulary schemas
  • sub-elements (like properties of types, elements of namespace) are indexed for predictable and fast read access

[chrisspre]

might be a duplicate of #2382

[corranrogue9]

I will follow-up with @chrisspre and @xuzhg to get more clarify about the path forward

[corranrogue9]

Related issue? #2321

[corranrogue9]

I am adding context from one of our investigations meetings to each of the EDM related work items. Please keep these scenarios in mind when investigating this work item:

It has been suggested (by myself) that removing the EDM interfaces and replacing them with concrete types where appropriate would be a good idea. 2 existing scenarios were enumerated for why the interfaces are necessary, 1 existing scenario was enumerated for why the interfaces are helpful (but not strictly necessary), 1 known future scenario was enumerated for why the interaces continue to be necessary, and 1 potential future scenario was enumerate for why the interfaces provide existensibility that wouldn't be available with concrete types.

Existing necessary scenarios

1. The interfaces are used today for mocking in unit tests
2. The interfaces could be used by customers to provide custom implementations for each type

Existing helpful scenarios

1. It is helpful to have a read-only view into the EDM models

Known future scenario

1. We want to allow customers to update their models after, for example, the model has been read from a CSDL file. The interfaces being a read-only view give the option for the concrete types to be used for post-read modifications, with the interfaces being used once those modifications are complete.

Potential future scenario

1. There is a potential scenario where the full model being loaded into memory is not necessary for a customer. With the current structure of the IEdmModel interface, this means that, if all other EDM types were concrete types, then any instance of IEdmModel would necessarily need to load portions of the model into memory even if those portions aren't used. A new implementation of non-model EDM interfaces would allow for this even though the concrete types would not.

[corranrogue9]

An additional point that has come up since my previous comment was added is that deriving from EdmType implies that the new type is part of EDM. If the new type is not, then we will not use it in a way that is conformant with the standard during serialization and deserialization. This would indicate that EdmType should be sealed. However, it is currently abstract and, regardless, each concrete type is built off of the IEdmType interface, which cannot be sealed. To me, this indicates that it is important to have more control over the class that implement the EDM types, and therefore not expose them as an interface.