xregistry / spec

xRegistry related specifications
https://xRegistry.io
Apache License 2.0
30 stars 6 forks source link

Resource vs Version model attributes #134

Open duglin opened 2 months ago

duglin commented 2 months ago

I think this might be related to @deissnerk's discomfort with our model...

I think we need to continue to have just Groups and Resources as part of the model definition itself. I think that 2-layer model is important to keep things simple and splitting Resources and Versions in the model will not only add to the perceived complexity but will require more work for people due to duplication of attribute definitions. However, I think we may need to be a bit more clear for client-side tooling.

Proposal:

Need to think about how this relates to other model attributes, like "serverRequired" or "readonly"

Examples: Attribute location readOnly serverRequired immutable
id both false true true
name inherited false false false
defaultversionid resource true true false
isdefault version true false false
user-extension inherited false false false
xref resource false false false
epoch version false true false
self both true true false
versionid version false true true

Then when we talk about "export" we can say:

Basically, we skip version attributes when exporting a Resource (i.e. don't show default Version attributes).

Are there other type of attributes I'm missing?

duglin commented 1 month ago

allow location=resource for administrative extensions (xref impls) to add, but not end-users since that would require code changes

duglin commented 1 month ago

Given the recent changes, I think we can reduce this down to: location=resource|version where the default value is version

to be clear, id and self will be version because they appear on both.

duglin commented 2 weeks ago

Going with location=resource|version|both