Re: CfC: Action name convention

One of the reasons we started with the URL namespace was to set a healthy
precedence which developers would adopt.  I'm concerned that developers
will see 'share' as an action and jump right to creating 'myfunctionality'
as an action.  This leads to an extremely narrow namespace for actions and
a high probability of collision.  It also means actions won't be
self-documenting by having the URL point to documentation for the action
(for both the standard actions and developer-provided actions).

Thanks,
James

On Thu, Sep 20, 2012 at 10:36 AM, Greg Billock <gbillock@google.com> wrote:

> We've discussed a couple possible options for action names: using
> "http://webintents.org/$ACTION", using
> "http://intents.w3.org/$ACTION", and using just "$ACTION".
>
> I'd like to propose that we establish the convention of just using
> "$ACTION" for common actions. That is, the namespace remains open, and
> it would remain a recommendation that new actions would namespace
> themselves as we originally planned -- with url-style namespacing. But
> the common actions to be documented in spec documents or
> recommendations or best practices documents by the task force would
> use bare names, like "share", "save", "pick", and "edit".
>
> The relationship to current actions are that there is no equivalence.
> That is, "http://webintents.org/share" is a DIFFERENT action than just
> "share". The strings are still to be treated as literals using exact
> matching. This allows us to experiment with actions using this or
> other namespaces (i.e. "http://webintents.org/experimental-action").
>
> If this idea attracts consensus, I'll update the spec examples to
> reflect it, and we who are working on Chrome will begin to transition
> our internal documentation and work to reflect that decision as well.
>
> I think this, and our discussions about the format for MIME types,
> means we're closing in on the contents of our interchange format best
> practices document, which Josh Soref proposed we add to the
> deliverables last year. I offer to begin work on that document; is
> there any formalism required for adding it to our deliverables? I can
> begin the document alongside the existing WD of the spec.
>
>