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

On Thu, Feb 27, 2014 at 12:37 AM, Savas Parastatidis <
Savas.Parastatidis@microsoft.com> wrote:

>  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…
>
>
I stated this elsewhere to Savas, but wanted to re-affirm it here: I'm 100%
in agreement here. I don't think OPTIONS can take us that far and the extra
round trip is not practical. I'm sorry if I misinterpreted my opinion
before, but just wanted to clarify here in case that happened.

Also, just as a larger distribution, I posted my thoughts on HTTP
invocation here (where I go over GET + hypermedia and where OPTIONS falls
short):

http://blog.sgo.to/2014/02/rows.html


>  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 <goto@google.com>
> *Sent:* ‎Wednesday‎, ‎February‎ ‎26‎, ‎2014 ‎6‎:‎36‎ ‎AM
> *To:* Markus Lanthaler <markus.lanthaler@gmx.net>
> *Cc:* Jason Johnson (BING) <jasjoh@microsoft.com>, W3C Web Schemas Task
> Force <public-vocabs@w3.org>, 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
>>>
>>>
>>>
>>
>