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

On Thursday, February 27, 2014 9:37 AM, Savas Parastatidis wrote:
> I would caution the use of OPTIONS.

+1, OPTIONS has a number of issues in practice. Responses can't be cached
and you can't easily link to those responses.


> 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…

Right, that's basically what Hydra does. Simply speaking, you either define
the operations inline or you define them by referencing an "ApiDescription
document".


> 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 :)

Fully agreed. On the mobile app side of things, however, it is necessary to
query for these operations (intents) anyway as you can't be sure that the
user installed the app. If there's a mechanism to find all possible actions
without having to describe them in detail beforehand, even better.


--
Markus Lanthaler
@markuslanthaler




------------- Original Message -------------
From: Sam Goto
Sent: ýWednesdayý, ýFebruaryý ý26ý, ý2014 ý6ý:ý36ý ýAM
To: Markus Lanthaler
Cc: Jason Johnson (BING), W3C Web Schemas Task Force, public-hydra@w3.org



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


On Mon, Feb 17, 2014 at 12:44 PM, Markus Lanthaler
<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 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

Received on Monday, 3 March 2014 17:53:34 UTC