How to extend Redfish schema ?

The PowerPoint is just some of the recommendations and isn't meant as a substitute for reading the spec (which has additional information). But you ask a very good question, so I'll comment.
You can't add it to an existing anything. The additionalProperties=false in the JSONSchema and similar rules in CSDL prevent this. But notice that every single resource has "OEM" in it and that construct does have additionalProperties=true. So that's the place you add the extension. There is a good example of this in ComputerSystem mockups for System/1 for an extension for a fictional company called "Contoso".

So let's assume your Company name or stock ticker is "XYZZY". You would do two things: 1) define a Schema in both CSDL and JSON Schema to match the payload you want to add and 2) put that Schema in the OEM section. Using your example of FrequencyScaling, I think it would go best in Processor resources under the processor collection. I don't think you should put it under ComputerSystem, but you might. You would never extend a collection. Those are un-versioned and really are just meant to be a "bag of stuff" with no properties/semantics other than being a bag.

So the actual Resource, with my company name being XYZZY, would look something like this:
{
    "@odata.context": "/redfish/v1/$metadata#Systems/Members/1/Processors/Members/$entity",
    "@odata.id": "/redfish/v1/Systems/1/Processors/1",
    "@odata.type": "#Processor.v1_0_0.Processor",
    "Name": "Processor",
    "Id": "1",
    "Socket": "CPU 1",
    "ProcessorType": "CPU",
    "ProcessorArchitecture": "x86",
    "InstructionSet": "x86-64",
    "Manufacturer": "Intel(R) Corporation",
    "Model": "Multi-Core Intel(R) Xeon(R) processor 7xxx Series",
    "ProcessorID": { <Snip> },
    "MaxSpeedMHz": 3700,
    "TotalCores": 8,
    "TotalThreads": 16,
    "Status": {
        "State": "Enabled",
        "Health": "OK"
    }
    "Oem" : {
        "XYZZY" : {
            "@odata.type": "http://schemas.xyzzy.com/XyzzyProcessor.v1_0_0.XyzzyProcessor",
            "FrequencyScaling" {
                "Status" : {
                    "State" : "Enabled"
                }
                "StepValuePercentage" : 10
            }
        }
    }
}
Notice a couple of things here:
1) Both the local JSONSchema (resource off of the root at /redfish/v1) and the $metadata should have references to this oem schema and the links header should have a rel value that points to it as well. And I might just want to put that file at "http://schemas.xyzzy.com/XyzzyProcessor.v1_0_0.xml" and "http://schemas.xyzzy.com/XyzzyProcessor.v1_0_0.json" or register it with the DMTF.
2) Notice that I used the Status property from Resource and used State from it. This is the unification/leverage that is talked about in the powerpoint deck of "Inheritance By Copy". Don't invent your own state/status mechanism. use the one the DMTF defined, even in your own schema.
3) The Schema would, in fact, just be a complexType and not a navigation property as I don't have an @odata.id or anything else. An example of schemas for those would be IPAddress. You can take it, rename it and modify it.

ONE MORE THING: This sounds like a pretty common feature that just wasn't included in Redfish (yet). You can almost be sure it will be at some point and will probably be different than what you have (we don't try to do that but it happens for technical reasons sometimes). We would greatly appreciate it if you would submit the idea through the DMTF Feedback Portal at www.dmtf.org/standards/feedback and if you did so within the next week or two, we should have it as part of the standard by the next release. In fact, I'll champion it myself if you would kindly submit it to be part of the standard.

1) You cannot add properties to BootSource as an OEM. They are a fixed enumeration as part of Redfish - that's how we get interoperability between implementations. You have a couple of choices: a) an OEM section that has a property like "additionalBootSource" or something or b) submit your enumeration additions to the DMTF through the feedback portal and see if they are willing to add them. If you want to discuss them here, we can give you a good idea if they are likely to make it in or not.
2) Yes, you do not have to have all of the values available in the array. That is why it is a property and not a schema definition. So you can do as you suggest.

While you could re-publish an edited (subset) schema, that isn't necessary nor something that would be expected. Redfish uses an "annotation" mechanism for properties like BootSourceOverrideTarget to inform the client what enumerations are supported by the implementation. This is done for certain read-write properties, so that the client can avoid trial-and-error PATCH requests.

The annotation takes the form of a separate property with the same name and "@redfish.AllowableValues" appended. In this case, "BootSourceOverrideTarget@Redfish.AllowableValues". For example:


"Boot": {
"BootSourceOverrideEnabled": "Once",
"BootSourceOverrideTarget": "Pxe",
"BootSourceOverrideTarget@Redfish.AllowableValues": [
"None",
"Pxe",
"Cd",
"Usb",
"Hdd",
"BiosSetup",
"Utilities",
"Diags",
"SDCard",
"UefiTarget"
]
},


Cheers,

Jeff

Jeff, thank you for explanation!