Those are all different phrasings of the same concept.
I know, I did say that no matter how you phrase it doesn't make it any more correct. Does that not reflect that I already understood you were rephrasing incorrect logic? Yet, you proceeded to attempt to enlighten me to the reality that that you're using different phrases for the same concept. I say: duh.
If SiriKit had an API for playing specific tracks, the developer would be able to append a query to the end of a URI (I've written Rails code for Spotify and Rdio, so I'm speaking from experience).
Incorrect.
You're attempting to sound like you understand, using Ruby URI principles for a situation that's actually not applicable. If the voice query originated in Spotify, then yes, Spotify would take that request and need to access Siri in order for Siri to do the required action. It would be basically saying, "Siri I got this request from this user, do this." And thus, the developer's app would need to access Siri. In that situation, then yes, the developer's app would need a way to query Siri. But that situation is complete fantasy / not reality, and very insecure.
You insist on not realizing that the query is actually originating within Siri, not within the developer app.
Seriously, it's very simple. What gets called first when a person says "hey, Siri"? Is it the developer's app that is called first, and processes the request, or is it Siri that is called first and then processes the request?
It is not the developer app that must take and handle that request, it is Siri that must take the request, and then query the developer's app. So in your incorrect URI analogy, it is actually Siri that would need to pend the query string to the developer's URI, and get a response from the Developer's app, not the other way around. The developer's app is not actually processing the request, it is Siri that takes the request and tells the Developer's app what to do. "Spotify play this." So in the reality of the situation, the developer's app doesn't need access to Siri because it's Siri that is accessing the developer's app, not the other way around.
There is no situation where a developer's app would need to tell Siri what to do.
When Siri gets a request to play a song, Siri doesn't actually play the song, Siri tells another app to play that song. So why would that other app ever need to tell Siri what to do? And if that other app never needs to tell Siri what to do, why would that other app ever need access to Siri?
But that whole URI concept is actually not applicable. The situation is simply that the developer's app needs to be exposed in a manner that Siri understands. This does not require the developer's app to access Siri. Instead it requires that the developer's app has key details exposed, in a predefined manner, that Siri can grab and understand the capabilities of the app. That simply requires Apple to define a way for developers to expose their apps. Which Apple already began and has done, they just haven't done it for all apps / situations.
Every single thing that you've said Siri needs, you're actually incorrect on.
You took on the stance that I didn't read the documentation that I referenced, and proceeded to try to educate me about the limitations. But for every single thing that you tried to explain what would be needed, is incorrect. Since I already read such perspectives as yours, I was able to see the flaw in logic long before you attempted to enlighten me. Is it really that difficult for you to see, that I've already been exposed to your ideas, and thus obviously read more than what you thought I read? lol. Due to actually understanding the situation I can see what is really needed, outside of what someone else is telling me that's needed. Your understanding is limited to the constructs that others define for you. I'm giving you knowledge that I didn't take from someone else.
So here you are trying to educate me on limitations that I already understand, using incorrect logic about things like "streaming control" "API URI" and other things that you think are correct / applicable but actually aren't. So I am addressing what you're saying almost like debating semantics, because what you're actually saying is wrong. The principle of what you're saying isn't wrong, the details are, because you don't actually understand the details. So how are you attempting to enlighten me on details that you don't even truly understand? That's pure arrogance. So I'm taking apart what you're saying. And by addressing the details, I'm reflecting that I actually know / understand the details.
--- edit ---
Seriously man, just check me out on LinkedIn and see that I've been an artificial intelligence programmer for more than a decade. You're not telling me things I don't already know.