681 Update Intent Naming Conventions

[mistryvinay]

Update Intent Naming Conventions

[kriswest]

Thanks Vinay, good start. I've added some suggested changes

A changelog entry is also needed in CHANGELOG.md

[kriswest]

I'm not sure we need this anymore and could replace with a comment that standardized intents are defined in the following pages, otherwise just cut it down to a bulleted list with each entry having a link to the relevant page...

[mistryvinay]

Hi @kriswest is there a way to have a directory of the Ref/ folde? As this will allow future intents to appear as and when they are added?

As currently I need to include a hyperlink for each definition.

[kriswest]

We've got the sidebar nav, but thats all. Hence, we either remove the list and just mention that the individual types are on subsequent pages, or manually add a link for each...

It would be fine (and probably easier) to do this all in a subsequent PR when we've got the full set of intent and context PRs lined up.

[kriswest]

LGTM

[robmoffat]

I think you should go further with the namespacing. I think that each intent should have a proper namespaced ID, and a display name.

• fdc3. is reserved for standardised FDC3 intents.
• anything else should be a domain that you own e.g. com.google.some.intent. (if it were google creating the intent).

I am not sure how this would affect intent resolution. It's possible that there could be multiple intents with the same English name.

This means if two apps are implementing the same intent, it's very clear, rather than just an accidental collision.

I am willing to accept that I might be completely off with this.. just wanted to know if it'd been discussed.

[kriswest]

@robmoffat Namespacing has been discussed previously. The standardized intents are not currently namespaced - adding that to them would of course be a breaking change and it was deemed unnecessary. There's also a long-standing issues in the API and appD (e.g. #312) regarding intent display names (currently configured by each app, which doesn't make sense) meaning having them bare/human readable can actually be useful. It also differentiates them slightly from context type names.

That leaves us with only optional namespacing for proprietary intents which is there purely to differentiate a proprietary intent and avoid collision, where the rest of the time you want people to be reusing the same intents and contexts to promote uptake of common workflows and interchangeability of components/widespread interop of applications.

All that said, I would prefer a situation where display names were sorted out and we could be using true IDs. However I think that's a different issue and we should pick up and deal with this on:

• The AppIntent interface incorrectly describes an intent #312
• an additional issue to add /contexts and /intents endpoints to the appD API or standardized types with display names (so you have somewhere authoritative to get the display names from rather than individual app configs).