feat: attrschema extension

[sasha-tkachev]

Technical definition is complete, only left to add an abstract

[devinbost]

Looks good to me. Thanks for all the work on this @sasha-tkachev !
I'd like to hear from others like @clemensv and @deissnerk since there may be edge cases I'm not considering.

[devinbost]

Looks like this is using draft-07 of JSON Schema. The current stable version is 2020-12. Is there a particular reason for not updating to 2020-12?

[sasha-tkachev]

no, fixing now

[devinbost]

Is this saying that additional properties (are these for extensions?) can be either boolean, integer, string, or binary types?

[sasha-tkachev]

Yes,
Or URIs, references and timestamps

[duglin]

REQUIRED

[duglin]

I'm not sure what "translated to another format" means. Can you elaborate?

[duglin]

While I understand the idea of converting everything to a string for the purposes of the check, it feels odd that "myattr" isn't defined as an int. It seems like we should check its "type" as part of the original format (if the format support types), and then check to see if the value is syntactically correct per the pattern/enum/...

[sasha-tkachev]

it SHOULD be defined as cetype of integer

[duglin]

JSON

[duglin]

Not sure this first sentence is needed since it's not saying what it's incompatible with. Either this URI describes the current attributes or not.

[duglin]

Can we add cetype and format to the example below?

[clemensv]

There's a lot of work here, but this unfortunately overlaps quite a bit with the work we've done on Discovery, especially in the area of message definitions.

The snippet below is code generated based out of Microsoft Azure Event Grid metadata for the Azure Storage service on the latest status of the discussion in the discovery group and uses the CloudEvents/1.0 format for a message description. We obviously should avoid having competing models for this.

The formats have a slot in the discovery spec, but the prose hasn't been written, yet. I have formal schema definitions for the CloudEvents format, though: https://github.com/clemensv/cloudevents-discovery-interop/blob/master/src/Azure.CloudEvents.Discovery/specs/ce_discovery.yaml#L618

        "Microsoft.Storage.BlobCreated": {
            "schemaurl": "https://raw.githubusercontent.com/Azure/azure-rest-api-specs/master/specification/eventgrid/data-plane/Microsoft.Storage/stable/2018-01-01/Storage.json",
            "id": "Microsoft.Storage.BlobCreated",
            "epoch": 0,
            "self": "https://discovery.example.com/groups/Microsoft.storage/definitions/Microsoft.Storage.BlobCreated",
            "description": "Raised when a blob is created.",
            "origin": "https://azure.com",
            "format": "CloudEvents/1.0",
            "metadata": {
                "id": {
                    "required": true
                },
                "type": {
                    "value": "Microsoft.Storage.BlobCreated",
                    "required": true
                },
                "time": {
                    "required": true
                },
                "source": {
                    "value": "/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Storage/storageAccounts/{storageAccountName}",
                    "required": false
                },
                "dataschema": {
                    "value": "https://raw.githubusercontent.com/Azure/azure-rest-api-specs/master/specification/eventgrid/data-plane/Microsoft.Storage/stable/2018-01-01/Storage.json",
                    "required": true
                },
                "datacontenttype": {
                    "value": "application/json",
                    "required": true
                }
            }
        },

[devinbost]

@clemensv Thanks for sharing your thoughts on this!
Does the discovery spec enable validation of the headers?
I agree that we don't want competing work.
I'm wondering where the line should be.

[sasha-tkachev]

I think we can close this

[duglin]

Closing per @sasha-tkachev's comment. Please let me know if we need to reopen it