Data structure of intents registered with IWC

[csl...@gmail.com]

I've got IWC successfully working with some applications I've developed to experiment with the data and intents API functionality.  With regard to intents, these applications all know the structure of the data that's expected by the other applications whose intent handlers they're invoking.  Is there any way to discovery this information for third party applications to whom I'd like to send intents but do not know the structure of the data they accept?  I haven't been able to find any explanation of this in the documentation, and the IWC debugger doesn't seem to indicate this in its list of registered intents, which makes sense since registering doesn't require including the data structure your intent handler is expecting.

[Ross Pokorny]

The data type that goes along with the intent is supposed to be all that is
necessary in order for each side to understand what the data should look like.
So for example, if a widget registers an intent under "/text/csv/view", that
widget should expect the data that comes in to be a valid csv file.

I suspect you are primarily asking about more open-ended formats, like JSON.
ie, how do the widgets know or agree on what particular JSON properties and
shapes to expect? Strictly speaking, the proper way to handle that is to make
up new data types for the specific JSON shapes in question. For example, lets
say that a map widget expects to receive a JSON object that represents a
coordinate and which looks like this:

{ "lat": 0.0000, "lon": 0.0000 }

In that case, the writer of that widget might make up a data type named
"application/vnd.my.map.widget.coordinate+json", which would be documented
somewhere to mean JSON that is structured as shown above. Then the widget
would register an intent with a name like "/application/
vnd.my.map.widget.coordinate+json/view" and other widgets would know that they
need to send that specific JSON format to that intent.

There are a few things to note here. For one, the data type names are meant
to be Internet Media Types. This means that unless you are using one of the
official ones, you should prefix the second part with "vnd." . Additionally,
note the "+json" on the end of the data type name. That is the standard way
to signify that the type is a specific kind of JSON. Please see RFC 6838 for
more info on both of those rules. Finally, I want to note that this system
will work best if the data types that are in use are publicized to he greatest
extent possible, so that the community can try to avoid having different
widget authors creating different, redundant data types.

Ross Pokorny