Resource Update Samples
February 19, 2026 ยท View on GitHub
This document shows a set of write operations that provide concrete examples of how the Resource Processing Algorithm is applied based on the state of the Registry and the incoming request. They are meant to be read in order to avoid repeating the same commentary for each example.
Table of Contents
- The Setup
- Create single Resource with empty content
- Create Resource via the "files" collection
- Create Resource with Versions, no defaultversionid
- Create Resource with Versions and defaultversionid
- Create Resource with Versions and unique defaultversionid
- Create Resource with defaultversionid
- Create Resource with defaultversionid
- Create Resource with versionid and Versions
- Update Resource with new Versions and sticky default Version
- Create Resource with Versions and sticky default Version
- Create Resource with versionid and defaultversionid
- Create Resource with sticky defaultversionid
- Update Resource with non-sticky bad defaultversionid
- Update Resource with sticky non-specified defaultversionid
- Patch Resource with Versions and defaultversionsticky
- Update Resource with empty content
- Patch Resource with empty content
- Update Resource with new description
- Patch Resource's description field
- Update Resource with non-specified defaultversionsticky
- Patch Resource with defaultversionsticky
- Patch Resource with sticky defaultversionid
- Patch Resource with bad defaultversionid
- Update Resource with bad sticky defaultversionid
- Update Resource with non-specified sticky default Version
- Create Resource with conflicting default Version attributes - variant 1
- Create Resource with conflicting default Version attributes - variant 2
- Create Resource with conflicting default Version attributes - variant 3
- Create Resource with SetDefaultVersionID flag
- Create Resource with SetDefaultVersionID flag via /versions
The Setup
Each example:
- Only includes the key attributes that are important from an "understanding" perspective.
- Includes explanatory text, highlighting the key aspects.
- Timestamps will only use a year or "now" (meaning it was updated to the current time) rather than a full RFC3330 timestamp to make it easier to detect changes in values.
- Has a model defined as:
{
"groups": {
"dirs": {
"singular": "dir",
"resources": {
"files": {
"singular": "file",
"hasdocument": false,
"versionmode": "createdat"
}
}
}
}
}
Create single Resource with empty content
|
Initial State:
Request:
|
Final State:
|
Notes:
- A new Resource
f1is created. - A Version with a
versionidof1is created per the defaultversionidnaming algorithm defined in the specification. - Conceptually, this new Version is populated with the Resource's default Version attributes from the request. However, since there are none, all mandatory attributes are assigned their default values.
- The Version's
ancestorvalue is1(points to itself) because it is the root of a hierarchy tree. - Being the only Version, it is the default Version, and it is not "sticky".
- Using
PATCHinstead ofPUTwill yield the exact same results.
Create Resource via the "files" collection
|
Initial State:
Request:
|
Final State:
|
Notes:
- Similar to previous example, but creating the Resource via the owning
Group's
filescollection. - The default Version properties include
name, so that will appear both at the Resource level and within the Version in theversionscollection.
Create Resource with Versions, no defaultversionid
|
Initial State:
Request:
|
Final State:
|
Notes:
- After creating the Resource,
f1, Versionsv1andv2are created. - Note that
namewill be ignored because whenversionidandmeta.defaultversionidare absent, butversionsis not empty, all Resource.* attributes are ignored. - Since all Versions have the same
createdattimestamp they are sorted alphabetically by theirversionidvalues in order to set theirancestorattributes. - Which means
v2becomes the newest and therefore the default Version. - Ancestor order:
1<-v1<-v2. - Using
PATCHwould yield the exact same results.
Create Resource with Versions and defaultversionid
|
Initial State:
Request:
|
Final State:
|
Notes:
- No Version
1is created because we usedmeta.defaultversionidas a clue that Resource.* attributes are forv1. - Resource.* attributes (eg
name) is ignored becausev1is part of the request'sversionscollection. - Ancestor order:
v1(2020) <-v3(now) <-v2(3030). - Version
v2is default because it has the newestcreatedattimestamp.
Create Resource with Versions and unique defaultversionid
|
Initial State:
Request:
|
Final State:
|
Notes:
- No Version
1is created because we usedmeta.defaultversionidas a clue that Resource.* attributes are forv1. - Resource.* attributes (eg
name) are assigned tov1. - Ancestor order:
v1(now) <-v2(now) <-v3(now). - Version
v3is default because it is the highest alphabetically.
Create Resource with defaultversionid
|
Initial State:
Request:
|
Final State:
|
Notes:
- Version
v1is created due tometa.defaultversionidbeing set. - Since
v1isn't part of the request'sversionscollection, the Resource.* attributes will be applied.
Create Resource with versionid and Versions
|
Initial State:
Request:
|
Final State:
|
Notes:
- Version
v0is created because it is not present inversions. - Ancestor order:
v1(2020) <-v0(now) <-v2(now).
Update Resource with new Versions and sticky default Version
|
Initial State:
Request:
|
Final State:
|
Notes:
- Version
v0(the current default Version) is updated with the Resource.* attributes. Notice thatversionidis not present in the request and that it isn't needed as a "clue" because the Resource already exists so we know what the current default Version is. - While
meta.defaultversionidis not used as a clue as to the "current" defaultversionid, it will be used to calculate the resulting default Version due todefaultversionstickybeingtrue. - Ancestor order:
v1(2020) <-v0(2021) <-v2(now).
Create Resource with Versions and sticky default Version
|
Initial State:
Request:
|
Final State:
|
Notes:
- In this case
versionidat the Resource level is needed to ensure that the current default Version isv0and that it is created. - Notice that the 2 potential "clues" (
versionidandmeta.defaultversionid) have different values because we need to createv0as the current default Version when processing the Resource.* attributes, but then assignv1as the resulting default Version. This means that in the previous exampleversionidwas not needed, but in this example it is to yield the correct (same) net result. - Ancestor order:
v1(2020) <-v0(now) <-v2(now).
Create Resource with versionid and defaultversionid
|
Initial State:
Request:
|
Final State:
|
Notes:
- Version
v0is created due to the presence ofversionid. Which meansmeta.defaultversionidis ignored for the purpose of determining the current default Version. However, it is also ignored when calculating the resulting default Version due todefaultversionstickybeingfalse. - Ancestor order:
v1(2020) <-v0(now) <-v2(now).
Create Resource with sticky defaultversionid
|
Initial State:
Request:
|
Final State:
|
Notes:
- In this case since
versionidis not present,meta.defaultversionidwill be used as the "clue" for the current default Version. - And, Version v1 will be the default and it's sticky.
Update Resource with non-sticky bad defaultversionid
|
Initial State:
Request:
|
Final State:
|
Notes:
- Current default Version is
v1, andv1is not in the request'sversionscollection, so it's "name" attribute is updated. - Version
v2is updated. - While
meta.defaultversionidreferences a non-existing Version, no error is generated because its value is ignored due tometa.defaultversionstickybeingfalse. - Ancestor order:
v2(2020) <-v1(2025).
Update Resource with sticky non-specified defaultversionid
|
Initial State:
Request:
|
Final State:
|
Notes:
- Notice that "Resource.name" is ignored because
v2(the current default Version) appears in the request'sversionscollection. - While the current default is
v2, settingdefaultversionstickytotrueonly takes effect after the default Version is recalculated. This is due to the fact thatPUTis a complete replacement andmeta.defaultversionidnot being in the request is akin to setting it tonullin the request. In the next example we'll see howPATCHchanges this semantics. - Ancestor order:
v2(2020) <-v1(2025).
Patch Resource with Versions and defaultversionsticky
|
Initial State:
Request:
|
Final State:
|
Notes:
- Resource.name is ignored due to
v2(the current default Version) being in the request'sversionscollection. - Since this is a
PATCH, unlike the previous example wheremeta.defaultversionidwas implicitly set tonull, in this case its value remains unchanged. So, whenmeta.defaultversionstickyis set totruethe current default Version becomes "sticky". - Ancestor order:
v2(2020) <-v1(2025).
Update Resource with empty content
|
Initial State:
Request:
|
Final State:
|
Notes:
- Notice that
nameis deleted becausePUTis a complete replacement of all attributes. - No attributes in
metaare updated.
Patch Resource with empty content
|
Initial State:
Request:
|
Final State:
|
Notes:
- Notice this time
nameis unchanged due to the use ofPATCHinstead ofPUT. - However,
PATCHdoes update theepochandmodifiedattimestamps of the current default Version. - The
metasub-object is unchanged.
Update Resource with new description
|
Initial State:
Request:
|
Final State:
|
Notes:
- Default Version's
nameattribute is deleted. - Its
descriptionis updated. - Its
epochandmodifiedatare automatically updated. - The
metasub-object is unchanged.
Patch Resource's description field
|
Initial State:
Request:
|
Final State:
|
Notes:
- Default Version's
nameattribute is unchanged. - Its
descriptionis updated. - Its
epochandmodifiedatare automatically updated. - The
metasub-object is unchanged.
Update Resource with non-specified defaultversionsticky
|
Initial State:
Request:
|
Final State:
|
Notes:
- The default Version's
nameattribute is deleted due to the operation being aPUT. Itsepochandmodifiedatare automatically updated. meta.defaultversionstickyis set totrue, and since there is only one Version the calculated default Version remains1.
Patch Resource with defaultversionsticky
|
Initial State:
Request:
|
Final State:
|
Notes:
nameis unchanged, butepochandmodifiedatare automatically updated.- As with previous example, Version
1becomes sticky. - The default Version's
nameattribute is unchanged, butepochandmodifiedatare automatically updated. meta.defaultversionstickyis set totrue, and since there is only one Version the calculated default Version remains1.
Patch Resource with sticky defaultversionid
|
Initial State:
Request:
|
Final State:
|
Notes:
- Notice the operation is directed to the
metasub-object, no attributes on Versionv1orv2are modified. - However, per the request, the default Version is set to
v1and it is sticky. - The
meta'sepochandmodifiedatvalues are updated. - Ancestor order:
v1(2025) <-v2(2025).
Patch Resource with bad defaultversionid
|
Initial State:
Request:
|
Final State:
|
Notes:
- While the request didn't set
meta.defaultversionstickytotrueexplicitly, settingmeta.defaultversionidvia aPATCHimplicitly setsmeta.defaultversionstickytotrue. If this operation usedPUTinstead, the error would not have been generated andmeta.defaultversionidwould have been ignored.
Update Resource with bad sticky defaultversionid
|
Initial State:
Request:
|
Final State:
|
Notes:
- Similar to the previous example, except using
PUT. Ifmeta.defaultversionstickyhad not been included in the request with a value oftruethendefaultversionidwould have been ignored.
Update Resource with non-specified sticky default Version
|
Initial State:
Request:
|
Final State:
|
Notes:
- Version
v2is created with acreatedatvalue of1998. - Version
v1is updated (name,createdat,epochandmodifiedat). - While
v2was just created,v1is still the default Version because it has a newercreatedatvalue. And it is now sticky per the request. - Ancestor order:
v2(1998) <-v1(1999).
Create Resource with conflicting default Version attributes - variant 1
|
Initial State:
Request:
|
Final State:
|
Notes:
- Resource.name is ignored because
v1is in request'sversionscollection. - Version
v2is default because it's the highest alphabetically.
Create Resource with conflicting default Version attributes - variant 2
|
Initial State:
Request:
|
Final State:
|
Notes:
- Resource.* attributes (implied "null" values because they're missing) are
ignored because
v1is in the request'sversionscollection. - Version
v2is default because it's the highest alphabetically, - Despite
meta.defaultversionidbeing specified, it is ignored when calculating the default Version becausemeta.defaultversionstickyis nottrue.
Create Resource with conflicting default Version attributes - variant 3
|
Initial State:
Request:
|
Final State:
|
Notes:
- Same net results as previous example.
Create Resource with SetDefaultVersionID flag
|
Initial State:
Request:
|
Final State:
|
Notes:
- Use of the
?setdefaultversionidflag has the same semantics as settingmeta.defaultversionid=v1andmeta.defaultversionsticky=true.
Create Resource with SetDefaultVersionID flag via /versions
|
Initial State:
Request:
|
Final State:
|
Notes:
- Same net results as previous example.