RE: App-to-App interaction APIs - one more time, with feeling

I'm trying to understand exactly why you see your example ("there was a person who invented a "math" protocol handler. For him it meant that formulæ be read out loud (because his mission is making the web accessible to people with disabilities including eyes) but clearly there was no way to bring a different target.") as something this initiative is blocked by or cannot serve.

If you were to create a custom, community-led protocol definition for math equation handling, like web+math, apps would send a standard payload of semantic data, as defined here: http://schema.org/Code, and it would be handled by whatever app the user had installed to handle it. Given the handler at the other end is sending back data that would be displayed in the page, there's no reason JAWS or any other accessibility app would be blocked from reading its output - on either side of the connection.

I can't really make sense of this part of your email, can you clarify? --> "Somehow, I can't really be convinced by such a post except asking the user what is the sense of a given flavour or even protocol handler which, as we know, is kind of error-prone. Agree?" Asking the user what sense of a given protocol? Are you saying we can't ask users what apps they want to have handle various actions? If so, we do this all the time, in every OS on the planet, and I wouldn't say that simple process is error prone. Maybe I am misunderstanding you?

- Daniel

From: Paul Libbrecht [mailto:paul@hoplahup.net]
Sent: Sunday, October 18, 2015 9:38 AM
To: Daniel Buchner <dabuchne@microsoft.com>
Cc: public-webapps@w3.org
Subject: Re: App-to-App interaction APIs - one more time, with feeling

Daniel,

as far as I can read the post, copy-and-paste-interoperability would be a "sub-task" of this.
It's not a very small task though.
In my world, E.g., there was a person who inventend a "math" protocol handler. For him it meant that formulæ be read out loud (because his mission is making the web accessible to people with disabilities including eyes) but clearly there was no way to bring a different target.

Somehow, I can't really be convinced by such a post except asking the user what is the sense of a given flavour or even protocol handler which, as we know, is kind of error-prone. Agree?

paul

PS: I'm still struggling for the geo URL scheme to be properly handled but it works for me in a very very tiny spectrum of apps (GMaps > Hand-edited-HTML-in-Mails-through-Postbox > Blackberry Hub > Osmand). This is certainly a good example of difficult sequence of choices.


Daniel Buchner<mailto:dabuchne@microsoft.com>
14 octobre 2015 18:33
Hey WebAppers,

Just ran into this dragon for the 1,326th time, so thought I would do a write-up to rekindle discussion on this important area of developer need the platform currently fails to address: http://www.backalleycoder.com/2015/10/13/app-to-app-interaction-apis/<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.backalleycoder.com%2f2015%2f10%2f13%2fapp-to-app-interaction-apis%2f&data=01%7c01%7cdabuchne%40microsoft.com%7cb93b5f788520457129d208d2d7da91a0%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=IxbwQKRykbEKCDtFAsFUtEEETfQXt7XUsVxt7iGy6fw%3d>. We have existing APIs/specs that get relatively close, and my first instinct would be to leverage those and extend their capabilities to cover the broader family of use-cases highlighted in the post.

I welcome your ideas, feedback, and commentary,

- Daniel