if ?nested isn't supported then import or create() with children can never be supported #220
Comments
duglin
changed the title
|
On 1/15 call - drop ?nested |
duglin
added a commit
to duglin/xreg-spec
that referenced
this issue
Jan 15, 2025
- typo and wording clarifications in main spec
- remove duplicate "compatibility" in schema, it's part of core attributes now
- replaced `?export` with `?compact` and just removes the dup info. Any
inlining would need to be requested by the client
- defined `/export` to be `/?compact&inline=*,model,capabilities`
- remove ?nested
- tweaks valid chars for ID: `[a-zA-Z0-9_][a-zA-Z0-9_.\-~@]{0,127}`
- IDs must be no longer than 128 chars
- s/$structure/$details/g
Fixes: xregistry#234
Fixes: xregistry#233
Fixes: xregistry#232
Fixes: xregistry#220
Fixes: xregistry#229
Fixes: xregistry#224
Fixes: xregistry#237
Signed-off-by: Doug Davis <[email protected]>
Fannon
pushed a commit
to Fannon/xregistry
that referenced
this issue
Jan 23, 2025
- typo and wording clarifications in main spec
- remove duplicate "compatibility" in schema, it's part of core attributes now
- replaced `?export` with `?compact` and just removes the dup info. Any
inlining would need to be requested by the client
- defined `/export` to be `/?compact&inline=*,model,capabilities`
- remove ?nested
- tweaks valid chars for ID: `[a-zA-Z0-9_][a-zA-Z0-9_.\-~@]{0,127}`
- IDs must be no longer than 128 chars
- s/$structure/$details/g
Fixes: xregistry#234
Fixes: xregistry#233
Fixes: xregistry#232
Fixes: xregistry#220
Fixes: xregistry#229
Fixes: xregistry#224
Fixes: xregistry#237
Signed-off-by: Doug Davis <[email protected]>
Signed-off-by: Simon Heimler <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Whether this is an issue or not depends on whether we think people can't support query parameters but still want to support uploading children? For example a non-code server - ala S3. However, in those cases I wonder if those are read-only servers, or the "write" path (if any) is via the native S3 interfaces instead.
So, the question is... do we want to support "import" w/o requiring
?nested? Or do we think the "are you sure?" check is unnecessary even if they can support query parameters?Options:
1 - keep it as is
2 - drop
?nestedand let the presence of the children be good enough - remove "are you sure?" check3 - add a
/importAPI that implies?nested, similar to how/exportimplies?inline=*The text was updated successfully, but these errors were encountered: