dmtf / rde-dictionary Goto Github PK

Schema's that include properties based on the excerpt annotations defined in Redfish schemas are not being handled by the RDE dictionary builder.

Hi I am trying to do only the decoding operation. Please let me know what is a PDR map.txt file and if possible can you send me few samples of the PDR map.txt?

I have a basic question about using RDE-dictionaries (Hopefully this is the right place to ask this question. If not, I apologize.)

Let's say my RDE device is capable of receiving BEJ of two redfish schemas, ProcessorMetrics and MemoryMetrics. Right now I can generate dictionaries for each schema individually. Then I can use ProcessorMetrics schema dictionary for decoding ProcessorMetrics BEJ blocks and MemoryMetrics schema dictionary for decoding MemoryMetrics BEJ blocks.

So I need to know the original schema type of a BEJ block before hand to use the correct dictionary.

But if I can have one concatenated dictionary for both ProcessorMetrics and MemoryMetrics, then I do not need to know the original schema type of a BEJ block. I can simply feed either a ProcessorMetrics BEJ block or a MemoryMetrics BEJ block to the same dictionary for decoding.

Is there a way to generate a concatenated RDE-dictionary for both ProcessorMetrics and MemoryMetrics using rde_schema_dictionary_gen.py?

Encoded info:

       "ActiveLinkTechnology" : "Ethernet",
       "[email protected]" : {
           "ApplyTime" : "OnReset"
        }

Decoded info by script:

       "ActiveLinkTechnology" : "Ethernet",
       "[email protected]" : {
           "ApplyTime" : ""
        }

I've attached files in case you want to check.
example.zip

The parameter CertificateURI in CertificateService's #ReplaceCertificate action is a link, but the dictionary generator is not recognizing this as a link and is instead pulling in the entire Certificate resource into the CertificateService dictionary. A similar problem is happening with ComputerSystem (#AddResourceBlock, #RemoveResourceBlock).

Regular resource properties corresponding to extra-schema links are being handled properly.

Annotation set's properties should not have annotation selector bit, since annotations also can be annotated. (yes, sounds tricky)
For example:

"@Redfish.Settings" : {
    "SettingsObject" : {
        "@odata.id" : "..."
    }
}

So here only "@Redfish.Settings" and "@odata.id" must have annotation dictionary selector bit, since they are from root of the dictionary. In other words only properties from root of annotation dictionary(those have '@' sign) should have annot selector bit 1.

1. Currently the dictionary builder encodes the name of the property that represents the action with just the Action name. Instead it should represent the action property as

   #Namespace.ActionName
   e.g. #Drive.SecureErase

2. All actions have 2 child properties
   target
   title
   Currently the dictionary builder does not include these properties.

Hi,

Is there any C++ library of encoder / decoder. Also, is there any reference example with the dictionary published by a RDE device, and doing a redfish request converted to BEJ & respond back.

Enum tuple value is an nint.
Enum tuple size should be equal to size of nnit encoded in this tuple.
Currently script sets enum tuple size to 1 meanwhile minimum value should be at least 2.

Consider a case of BEJ encoding a simple erroneous JSON payload using the most recent version of the Redfish Volume schema:

{
    "Encrypted": "true"
}

This payload is considered erroneous because the schema defines the Encrypted property as having a type of either boolean or null, and a string type value has been assigned.

The python function json.loads() will convert this JSON object to the following python dictionary:

{
    'Encrypted': 'true'
}

When this dictionary is fed into bej_encode() with a string value for the 'Encrypted' key, the BEJ encoding succeeds with a False value being assigned to the property instead of failing the encode since the provided value was a string type.

It looks like the function which determines the appropriate BEJ format encoder to call for a given tuple, bej_encode_sflv() is not doing any sort of type validation for provided property values. Some simple checking for obvious type mismatches, primarily for int, bool, string, and float, would help to avoid unexpected outcomes during the encode process.

The human readable .map files that are generated alongside dictionary files should begin with the command line that was used to generate them. This will serve as internal documentation and will help ensure reproducibility of dictionary builds.

When dictionary entry has Nullable flag, encoder should have possibility to encode relevant JSON property with null value as a BEJ_NULL.

Without access to collection schemas, links to them are not created properly (reasonable) but no error message is generated to alert the user that these properties are being skipped (which seems wrong). While the situation is clearly user error, a warning message seems necessary.

The specific case where this was observed was in building a dictionary for NetworkAdapter. When the user first built the dictionary, no entries were generated for NetworkAdapter.NetworkPorts and NetworkAdapter.NetworkDeviceFunctions. Copying the two collection files into the directory with generate_dictionaries.py enabled them to be generated in this user's case.

Hi,

My device doesn't support Writes for some of properties which appears in schema profile as a ReadWrite.
To generate a dictionary I'am using a profile where I'm specifying those properties with only ReadRequirements as mandatory,
but in dictionary they appears as ReadWrite ones.
Is there a way to reflect such properties as ReadOnly in dictionary?
If no, then is it a script issue or "Redfish Interoperability Profiles"(DSP0272) spec issue?

The annotations schema is currently at v1_1_0 / v1_1_1, but the folder-based script hard-codes the "redfish-payload-annotations" version to "v1_0_0".

The script should either allow that value to be configurable, or, since these are backward compatible, just use the highest-version / latest annotations schema. Also suggesting to the DMTF that a "redfish-payload-annotations-v1.json" file be created to always reflect the latest version to avoid these ties - as was done for the "redfish-schema-v1" schema extensions file.