Hi Andy, On 02.06.25 16:48, Andrew (andy) Newton wrote:
I didn't want to put the cart before the horse. If we agree in the discussion below I can propose the text.On 6/2/25 03:43, [email protected] wrote:Hi,[PK] I'm not happy with "technical solution cannot otherwise be defined" as this is a condition likely impossible to fulfil or proof, as there will be always some solution possible. This also does not express the prime motivation for bare identifiers use:If you have some other words, please propose them.
- when identifier is generic and is a building block of RDAP protocol itself, backed with an IETF RFC -> analogy to standards tree media type registrationThis seems to be defining some new class of building block extensions that do not exist.
We haven't named them, but they exist. Versioning or "An RDAP With Extensions Media Type" (a.k.a rdap-x) just to name few.
An alternative would be to always have to update std95 if we would want to add a new "top level" not prefixed element.
I mentioned it as it was referred to in -04 4.5. But you are right, paths, query parameters and object class names have the same properties.- when the extension is only adding a single JSON propertyWhy just JSON as they could also apply to paths, query parameters and object class names? And why is JSON the exception when the negative implementation feedback is specific to JSON?
If there is a single item added by the extension, and it's equal to extension identifier - it's all same.
For class names and query parameters if an extension would want to add several there is no other choice than prefix, as the same name cannot be duplicated.
For JSON names and paths one may do a container with one name and include all needed values in there, or have a flat list with prefixes. It would be "foo_val1": "..." vs. "foo":{ "val1": "..." } for JSON, or foo_subpath1 vs foo/subpath1 for paths.
Kind Regards, Pawel
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
