Anonymous non-uniform property?

[jrep]

How can I define a (named) Attribute for this structure?

I'm documenting an API that, at one point, returns something like this:

{
    "tag1" : [ 1, 2, 3],
    "tag2" : [2, 4, 6, 8],
    "tag3" : [1, 1, 2, 3, 5, 8, 13]
}

But not quite like that: on any given call, depending on the app state, there might or might not be values for any given tag. If a given tag has no values, then it's entirely suppressed (no empty sub-array or null value). So this, also, is a possible return:

{
    "tag2" : [3, 1, 4, 1, 5, 9, 2, 6, 5, 3, 5],
    "tag3" : [3, 4, 5]
}

And likewise all of the other subsets.

To top it all off, that set of tags is useful in its own right (e.g., as an URI Template Parameter for "just give me any tag2 values").

There's a hauntingly inviting section in the MSON book, Non-uniform Property, but it seems to require me to name the non-uniform entity. But it has no other name than "+ Body", and Blueprint seems to require an URL associated with every Asset definition.

[zdne]

@jrep I think this is related to what are we discussing here #26 (comment) any ideas on that would be appreciated!

[zdne]

@jrep Was this answered in #26 (comment) or is this still an open question?

[jrep]

Hmm ... well, for other reasons, the actual case that got me started was redefined in a simpler way. Originally it was something like

GET /path/to/stuff
=> { "tag1" : [1,2,3], "tag2": [1,4,7] }

and also

GET /path/to/stuff/tag1
=> [1,2,3]

(and also a lot of "SQL SELECT type" URIs to be more specific about what to return)

I had wanted to give a type-name to the list of possible tags, and then in many places to declare that this URI parameter, that query parameter, or this other body object member was an instance of that type.

But the first form was eliminated. Also, since asking the question, I have learned that the set of tags is too large (over 100 values, and in fact run-time extensible) to actually list in the Blueprint. So I kind of dropped the thread.

Status now seems to be:

• I no longer actually care, so it's only hypothetical
• cases I do care about are simpler, and well handled by MSON
• but, no, I don't see how the hypothetical case is covered by mson#26