Week of March 3

- fix typos in doc/contributors.md
- get rid of `clientrequired` and rename `serverrequired` to just `required`.
  It now means "this attr MUST have a non-null value" without saying who
  provides it.
- mentioned we're http-only today but it might change in the future, and at
  that time we'll have a clean separation between core & http
- Add an "Implmentation Customizations" section to talk about adding authN/Z
  and other types of customization logic
- Allow ANY model changes as long as all entities are compliant with new model
  prior to completing the request. Server MAY choose to update data, or reject.
- Remove "maxmaxversions" capability
- Servers must accept "0" for maxversions but can prune at any time, even at 1.
- Add "relaxednames" aspect to "object" typed attributes, to allow "-" in names.
  And updated our model files to use "-" in some attribute names

Fixes: #267
Fixes: #230
Fixes: #264
Fixes: #270
Fixes: #271
Fixes: #273
Fixes: #272

Signed-off-by: Doug Davis <[email protected]>

Author: duglin

cloudevents/schemas/document-schema.json

@@ -5,31 +5,31 @@
       "type": "string",
       "readonly": true,
       "immutable": true,
-      "serverrequired": true,
+      "required": true,
       "default": "0.5"
     },
     "registryid": {
       "name": "registryid",
       "type": "string",
       "immutable": true,
-      "serverrequired": true
+      "required": true
     },
     "self": {
       "name": "self",
       "type": "url",
       "readonly": true,
-      "serverrequired": true
+      "required": true
     },
     "xid": {
       "name": "xid",
       "type": "xid",
       "readonly": true,
-      "serverrequired": true
+      "required": true
     },
     "epoch": {
       "name": "epoch",
       "type": "uinteger",
-      "serverrequired": true
+      "required": true
     },
     "name": {
       "name": "name",

cloudevents/schemas/openapi.json

@@ -657,3 +657,20 @@ the authors chose to have the server ignore unknown query parameters. It is
 worth noting that the specification says they SHOULD be ignored, not that they
 MUST be ignored. So there is room for an implementation to be very picky if
 needed, but at the risk of potentially causing interoperability problems.
+
+# Updating attributes with `ifvalues`
+
+The `ifvalues` feature might be a new concept for some readers, so a point
+of clarification might be useful. If an attribute is defined with an `ifvalues`
+aspect, then if that attribute's value changes it is possible that the
+set of sibling attributes that are part of that entity's model could change
+due to a new `ifvalues` match (or due to no match at all).
+
+When a client is performing a write operation that changes that attribute's
+value, the client must ensure that the net result of the changes are compliant
+with the resulting model. Meaning, if that attribute's new value adds or
+removes attributes then the client might need to also change other attributes
+in the entity in order to be model compliant.
+
+Likewise, implementations of the server must validate the entire entity
+against the new model, not just a subset of the entity's attributes.

core/model.json

@@ -16,14 +16,14 @@ Contributions do not constitute an official endorsement.
 - **Google**
   - Jon Skeet - [@jskeet](https://github.com/jskeet)
 
-- ** HDI Global SE**
+- **HDI Global SE**
   - Manuel Ottlik - [@manuelottlik](https://github.com/manuelottlik)
 
 - **Microsoft**
   - Clemens Vasters - [@clemensv](https://github.com/clemensv)
 
 - **Particular Software**
-  - Laila Bourgria - [@lailabougria](https://github.com/lailabougria)
+  - Laila Bougria - [@lailabougria](https://github.com/lailabougria)
 
 - **SAP**
   - Klaus Deissner - [@deissnerk](https://github.com/deissnerk)