The Redfish specification requires a Redfish implementation to expose its metadata document.
But together with RDE devices the final set of schemas may become varying (for example if a system implements pluggable add-ins with non-dmtf-defined schemas).
Moreover, an RDE device provides schema binary dictionaries instead of XML, so it may be not possible at all to update the metadata document in this case.
In order to comply with another Redfish requirement the RDE specification provides mechanism of getting formal metadata URI for the data in response (via Link / described by header).
So, in the end a redfish client is capable of getting schema for the requested data. But not a generic odata client which searches for schema in the $metadata document.
Should Redfish implementations for such cases somehow tell clients that the metadata document may be incomplete? Or even more, Redfish implementation should gather RDE device schema URIs in a special collection where clients know they should be? However, I guess for generic odata clients this may be not helpful either.
I think this might be something we need to discuss further in the forum.
TECHNICALLY implementations require a complete $metadata document that ensures clients can resolve all namespaces found in all payloads. RDE makes things difficult in that this can be dynamic based on devices inserted and removed. You could have a dynamic $metadata document to account for this, but this might not be realistic; generally speaking, $metadata is a static file in implementations.
From my perspective, I think we may need to relax some of the requirements in this space.
I also thought of dynamic $metadata document. Particularly, ETag could be used for tracking changes in the $metadata document. But I'm not sure if such behavior accommodates with the OData spec requirements. It seems that this part may be impossible to reconcile.