The Redfish specification applies definition that a resource collection is a set of resources that share the same schema definition.
The way it is formulated leaves me with the following three interpretations: 1. All members in a collection must be of the same type which is based on the collection element type. - collection(sensor.sensor) consisting only from sensor.v1_0_0.sensor resources (based on sensor.sensor) is valid - collection(sensor.sensor) consisting from sensor.v1_0_0.sensor resource and other resources (based on sensor.sensor) is invalid
2. All members in a collection must be of types based on the collection element type and must be defined in the same schema (namespace). - collection(sensor.sensor) consisting of mysensor.v1_0_0.discretesensor (based on sensor.sensor) and mysensor.v1_0_0.numericsensor (based on sensor.sensor) is valid - collection(sensor.sensor) consisting of mysensor.v1_0_0.discretesensor (based on sensor.sensor) and mysensor.v1_1_0.numericsensor (based on sensor.sensor) is invalid
3. All members in a collection must be of types based on the collection element type and can be defined in different schemas (namespaces). - collection(sensor.sensor) consisting of mysensor.v1_0_0.discretesensor (based on sensor.sensor) and mysensor.v1_1_0.numericsensor (based on sensor.sensor) is valid
Could someone elaborate how to perceive the definition?
The "namespace" vs. "schema" is a construct that came from the adoption of OData and the CSDL schema language. It's used for providing versioning information about each schema, but not for multiple definitions. There is exactly one "resource type" per schema file, even though there are numerous namespaces (for versions and for some shared object definitions).
A Resource Collection can contain any number of compatible resource versions, but no other resource types. - You could see a collection of "Sensor", containing "Sensor.v1_0_0", "Sensor.v1.3.0", and "Sensor.v1.8.2". But it could not contain a "Chassis.v1_3_0".
So your #1 is correct. But #2 can't happen because Redfish would not create different resource definitions within a schema. If we create a DiscreteSensor, it would get it's own schema file and definition, not be something that would be included in the Sensor_v1.xml schema file.
And your #3 is partially correct in that a Resource Collection can contain different versions of a schema, but again, your example has two different resource definitions coming from a single schema file which would not occur in Redfish.
We should add some variation of versions in some of our public mockups so there's an example of this...
Short answer is, as you expected, no, that would not be allowed. All members of a resource collection must use the same schema.
We don't use inheritance in the Redfish models to avoid the model complexity that it creates. In cases where we've found a reason to "extend" a schema definition for another purpose, we copy the definitions into a new schema. We call this "inheritance by copy" - and yes, it creates work for the schema writer to maintain them and keep them in sync if that is desired - but that's our job.
You can also use the OEM section within a resource to extend a schema to cover something unique to your product or design, while still fitting into existing models for the majority of the data.
Also, since you used "DiscreteSensor" as an example - if there's something missing in the "Sensor" model that could be added to cover your case, please provide that feedback! We didn't describe a discrete sensor in the model (yet), because we didn't have a use case for one. That doesn't mean we no one has a discrete sensor, but instead, in the Redfish design tenets we would much rather define a property to show the actual "purpose" of that discrete sensor value. For example, a "door sensor" would be rendered instead as "DoorStatus": "Open" or "Closed".
The Redfish design tenets are well understood, but it seems, at least from the sensor perspective, they are too restrictive for fast prototyping.
We want to adapt Redfish as a management interface for devices where SAF HPI or IPMI was previously employed, and bound to a problem of mapping a variety of sensors and controls into the schema. As I mentioned before, we want to expose several discrete sensors types, but maintaining them in the Sensors collection seems inappropriate because the Sensor resource is targeted on exposing a numeric sensor. I think I wouldn't be wrong if I guess that some other companies break their heads on this problem too.
Ultimately, according to the Redfish design tenets, all new sensors/controls will be somehow wrapped up by some new meaningful resources. But there always be a need for supporting new kinds of sensors or controls in a timely manner, and preferably in a standardized one.
And I'm just trying to figure out whether it is worth adding standard Redfish schemas for a collection of raw sensors and raw controls for quick system prototyping.
Such, I assume two collections of raw sensors and raw controls within a Chassis which will contain resources with some shared schema and path, but with specifics defined in Oem property.