Re: ActionHandlers vs "App resources" (was: An updated draft of the schema.org/Action proposal)

I would caution the use of OPTIONS.

Why move beyond hypermedia? A representation of a resource (eg RestaurantX) may contain a link to a resource that provides more information about the actions that can be performed. Or those actions can be described as part of the representation. Or the representation may tell us that the resource is linked with the resource http://schema.org/Restaurant for which actions have be defined. Or...

My point is that are multiple ways to represent information as a set of hypermedia resources without needing to us HTTP OPTIONS.

I argue that we should stay in the realm of HTTP GET for our publishing needs :)

Sent from Windows Mail

From: Sam Goto<mailto:goto@google.com>
Sent: ?Wednesday?, ?February? ?26?, ?2014 ?6?:?36? ?AM
To: Markus Lanthaler<mailto:markus.lanthaler@gmx.net>
Cc: Jason Johnson (BING)<mailto:jasjoh@microsoft.com>, W3C Web Schemas Task Force<mailto:public-vocabs@w3.org>, public-hydra@w3.org<mailto:public-hydra@w3.org>




On Fri, Feb 21, 2014 at 12:21 PM, Sam Goto <goto@google.com<mailto:goto@google.com>> wrote:



On Mon, Feb 17, 2014 at 12:44 PM, Markus Lanthaler <markus.lanthaler@gmx.net<mailto:markus.lanthaler@gmx.net>> wrote:
On Friday, February 14, 2014 7:11 PM, Sam Goto wrote:
> On Fri, Feb 14, 2014 at 9:33 AM, Markus Lanthaler wrote:
>>> 2) How would you be able to express that you CANNOT BuyAction on the
>>> AndroidAppLink resource (e.g. your mobile app resource isn't as fancy
>>> as your website)?
>>
>> That's something we would need to decide. I think in most cases
>> these resources are not really exactly the same. Thus, I'm not
>> sure whether it makes that much sense to "inherit" the operations
>> from the Web resource. I think it would be sensible to require
>> them to be declared separately. I don't think "expects" etc. are
>> needed for apps, are they? If not, it's really just a short list of
>> supported operations similar to the one in your example above, likely
>> with min. version constraints etc.
>
> Not quite on both points.
>
> 1) Most often than not, these are the same resources. That's the basic
> premise of the android-app://foobar.com/resource/1234<http://foobar.com/resource/1234> with rel=alternative
> links.

Fair enough. How do you thought of dealing different sets of operations then? You moved the list out from the action handler, didn't you?



You'd have specific action handlers attached to the action. Example (of a Movie that can be "watched" on android and "bought" via a webpage):

{
@type: Movie
action: [{
  @type: WatchAction
  handler: {
    @type: AndroidHandler
  }
}, {
  @type: BuyAction
   handler: {
     @type: WebPageHandler
  }
}
]
}

How would we go about this using sameAs/alternate?

Here is an interesting idea:

At run time, both android as well as HTTP allows you to "check" whether a specific operation is available in a specific resource (for HTTP that's an OPTIONS request).

On Android, you can query the intent system to check whether a specific application listens to a specific intent. I think this should work, but I'm investigating. Here is a code snippet [1].

Jason J, could you explore whether something like the following [1] would work for windows native applications?

If we have "run-time" mechanisms to query these "operations", the App Url mechanism could potentially replace ActionHandlers (which I agree is overall a better design).

Lets keep exploring this path.

Additionally, anyone can think of any other challenge we may face with the change?

[1]


Intent intent = new Intent(WATCH_ACTION);
intent.setDataUri("android-app://com.netflix/movies/1234");
List<ResolveInfo> resolveinfo_list = activity.getPackageManager().queryIntentActivities(intent, 0);

for(ResolveInfo info:resolveinfo_list){
  if(info.activityInfo.packageName.equalsIgnoreCase(application_name)){
    launchComponent(info.activityInfo.packageName, info.activityInfo.name);
    break;
  }
}




> 2) "expects" apply to apps as much as web resources. as you are
> "buying" an item on the web or in an app, things like your credit
> card / quantity information needs to be passed either way. That
> is, i'd expect to see things like
> http://amazon.com/products/1234?action=buy&quantity=2 as much as
> things like android-app://com.amazon/products/1234 with
> putExtra("quantity", "2") in the intent extra bag.

So you don't just open the specific screen in the app but you really carry out an operation (or at least pre-fill a form)? Where comes the data from to invoke the operation or pre-fill the form? Is there an intermediary UI (such as the review widget in Gmail)?

Right, that's the review widget in gmail case.




--
Markus Lanthaler
@markuslanthaler