This question is a similar problem, except for Java package names. The Java Specification suggests the domain convention, but it is not mandatory. Their choice is explained as follows:
The suggested convention for generating unique package names is merely a way to piggyback a package naming convention on top of an existing, widely known unique name registry instead of having to create a separate registry for package names.
Following are some options and their main advantages and disadvantages.
UUID
Advantages:
- Simple
Disadvantages:
- Not human readable
URL
Advantages:
- Conventional - "everybody else is using it".
- You can link to the schema/website that provides additional information.
Disadvantages:
- Domains cost money and expire
- But they don't cost that much. There are also some free domain services available (which are mostly subdomains). These services don't tend to be that reliable or long lived (you don't control the domain).
- If you use code hosting, you can use the URL of the project.
- Companies change, code is transferred and domain becomes irrelevant.
Advantages:
- Almost everyone has an email, or if they don't, there are reputable companies offering them for free.
Disadvantages:
- Emails change, authors change, it makes no sense with multiple contributors, and it becomes irrelevant.
Tag URIs
From Joe's answer.
Advantages:
- Specifying a date solves the issue of not owning the email/domain in the future.
Disadvantages:
- Same as for emails/domains in that they tend to change over time and are irrelevant to the project.
Anything
Advantages:
- Simple, quick, good for experimental or personal projects.
Disadvantages:
- May conflict with other namespaces in future.
Conclusion
I think the best solution in the end is a UUID plus maybe a canonical project name (you may run into problems if you want to change the name). Domains/emails aren't relevant to a project and are just a way to provide uniqueness, which is obsoleted by UUIDs.