Difference between revisions of "Namespace"

From MgmtWiki
Jump to: navigation, search
(Created page with "==Full Title or Meme== A Namespace is simply a list of names and some of their attributes. ==Context== ==References== {Category: Semantics]]")
 
Line 3: Line 3:
  
 
==Context==
 
==Context==
 +
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
 +
raised_hands
 +
 +
 +
 +
 +
 +
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.  http://microformats.org/wiki/namespaces-considered-harmful
 +
 +
  
 
==References==
 
==References==
  
{Category: Semantics]]
+
[{Category: Semantics]]

Revision as of 10:26, 25 October 2021

Full Title or Meme

A Namespace is simply a list of names and some of their attributes.

Context

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 raised_hands



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. http://microformats.org/wiki/namespaces-considered-harmful


References

[{Category: Semantics]]