Difference between revisions of "Namespace"
(→References) |
(→Context) |
||
Line 25: | Line 25: | ||
that is the best representation I could think of with the use of unencoded reserved chars | that is the best representation I could think of with the use of unencoded reserved chars | ||
− | this might be worth a discussion in the ID meeting later today. It is symptomatic of any attempt to create a universal semantic and why past attempts (X12, XML) have not been successful. http://microformats.org/wiki/namespaces-considered-harmful | + | this might be worth a discussion in the ID meeting later today. It is symptomatic of any attempt to create a universal semantic and why past attempts (X12, XML) have not been successful. |
+ | |||
+ | ==Problems== | ||
+ | |||
+ | * [http://microformats.org/wiki/namespaces-considered-harmful namespaces considered harmful] | ||
==References== | ==References== |
Revision as of 12:08, 26 October 2021
Full Title or Meme
A Namespace is simply a list of names and some of their attributes.
Context
- A namespace ensures that all of a given set of objects have unique names so that they can be easily identified.
- Namespaces are commonly structured as hierarchies to allow reuse of names in different contexts.
- An Entity is an Object with a name that is unique in some Namespace.
- A Taxonomy is the simplest form of a namespace.
- A typical Namespace can be uniquely discovered with a URL.
I am dealing with a particularly interesting challenge, wherein I don't want params that are transferred into a composed Service URL, I want some that are used in other aspects of a resulting request, like a POST body. The rub is that I have many params I would need, and don't want to start adding their generic names to the public namespace, because they are basically Service-specific white_check_mark eyes
9:00
What are we doing about Service specific params used in something other than transference to a composed URL?
9:01
I have this example right now of one possible way I was going to do this: ?messages=method:'CollectionsQuery',tags:'foo','bar',schema:'http://schema.org/MusicPlaylist' (edited)
9:01
Basically one param with multiple subelements
9:01
no standard exists for complex json value representation in params, that I am aware of
9:02
that is the best representation I could think of with the use of unencoded reserved chars
this might be worth a discussion in the ID meeting later today. It is symptomatic of any attempt to create a universal semantic and why past attempts (X12, XML) have not been successful.