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:p...@hoplahup.net]
Sent: Sunday, October 18, 2015 9:38 AM
To: Daniel Buchner <dabuc...@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:dabuc...@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
