Relating heterogeneous items

[Trevor Leffler]

Hi,

In a previous post [1] Mike wrote that he typically returns an items array of heterogeneous item objects.  This is to help improve UX/DX and reduce client overhead.  He wrote, 'i usually use a "type" data element to group like kinds of items and a "parent" or "childOf" to match related items.'  Is parent/childOf a link relation?  A data element?  If a data element, what is its value?  I can think of the value being some type-Id combo or I suppose a throw-away 'item Id' unique amongst the item objects.  How are you implementing this?

Here's a toy example we can use:  a user searches for appointments that occur next week.  A Cj document is returned with various appointment-, person-, and location-type items.  An appointment has person items and [probably just one] location item.

I'm attracted to the idea of heterogeneous items because I'd like to include nested/hierarchical data that isn't yet exposed via its own service endpoint (no URL yet) and both the inline and embedded extensions seem to rely on href attributes for matching parents to children.

Thanks for any input.

--Trevor

P.S. As an aside, could you give an example where using heterogeneous items improves UX/DX?  It's not clear to me.

[1] https://groups.google.com/d/msg/collectionjson/W3Gsb286cqo/DTtMwFGohGgJ

[mca]

Trevor:

here's an example of a mixed collection: https://gist.github.com/mamund/7337187 

in this case a data element named "type" is used to indicate what "kind" of item it is (user, account, activity) and there is no attempt to identify *relationships* between the items. this is just a mixed bag of items.

here's an example of a related collection: https://gist.github.com/mamund/5271749

in this case, the items *are* related and link elements in each item are used to indicate that. for example, the "type" link tells the client what "kind" of item it is (order or lineItem) and the "collection" link indicates which lines are related to which order.

I think this is the kind of information you are asking about.

the main point, however, is that these are "patterns of use" for Cj representations -- not standards or constraints. you're free to design your own approach to solving this problem and i'm quite interested to see how others are doing this.

cheers.

mca

+1.859.757.1449
skype:mca.amundsen
http://amundsen.com/blog/
http://twitter.com/mamund
https://github.com/mamund
http://linkedin.com/in/mamund

--
You received this message because you are subscribed to the Google Groups "Collection+JSON" group.
To unsubscribe from this group and stop receiving emails from it, send an email to collectionjso...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Trevor Leffler]

Thanks for the reply, Mike.

I hadn't yet seen that second example.  The use of link objects to relate an item to a type is interesting.  Mostly in that the href's value would seem to be used as a URN by the client, while humans could enjoy using it as a resolvable URL to go read the type and its definition.  I suppose this method has that advantage over a 'type' data object in the item's data array.

Anyway... I'm tossing around the idea of defining data objects with names 'itemType', 'itemId', and 'childItemId'.  My implementation would assign values to itemId unique within the context of the current Cj document.  The values would be subject to change and re-use across Cj documents.  An item's data array could have zero or more data objects with name 'childItemId' whose value would be one of the assigned itemIds.  No changes to the Cj doc, so this is just domain-specific semantics and documentation and desired client behavior on how to treat these items.

An example: https://gist.github.com/tleffler/0c74c0bceae68a313fdd

I was vaguely tempted to promote these data names to item attributes (becoming an extension) because you might argue they're item metadata.  Alternatively these data names could be prepended with 'cj' or '_' to highlight their, ahem, "meta-ness."  But, meh.

Hrm... but back to href's as URNs... I may simply be porting your ordersAndLines-cj gist from link object to data objects.  I've been so tied to the idea that all the hrefs must be resolvable.

--Trevor

[mca]

if you want to "standardize" the "_item*" elements, consider adding a "meta":[...] collection to each item and placing them there. you can drop the underscore as a semantic indicator and use the meta-space for other (future) elements. 

i think someone created a "meta" extension already, too. this might already exist or be easy to extend.

mca

+1.859.757.1449
skype:mca.amundsen
http://amundsen.com/blog/
http://twitter.com/mamund
https://github.com/mamund
http://linkedin.com/in/mamund

[Trevor Leffler]

I haven't found anything on this list or in the extensions repo regarding a meta extension.  But I'm thinking that it adds a 'meta' attribute to the item object, and its value could be an array of data objects.  Sound like a fair start?

--Trevor

[Trevor Leffler]

I ixnayed the "meta object isa data object" idea, making an item's "meta" attribute point to an array of metadata objects.  A metadata object has name and value attributes, as defined by the Cj spec.  "name" is required, "value" is optional.  No prompt or other things that an implementer may have extended onto data objects.  --Trevor