Creating an XML namespace without a domain

Question

Usually tutorials tell you to use your own domain name when making a new XML namespace. Not everybody owns a domain, it costs money, and the site might be unrelated to the purpose that you are using the XML for.

What is a good alternative?

In this answer, the example just has some_identifier, however Wikipedia says it is a URI. URIs can be URLs or URNs.

URLs can provide a link to the schema, however the primary purpose of the namespace is to be a unique identifier, so a URN fits better.

How do you generate a unique identifier? UUIDs are good for identifiers, so I searched and there is even an example on W3C:

<?xml:namespace ns='urn:uuid:C4ED1820-6207-11d1-A29F-00AA00C14882/'
                src='http://www.w3.org' prefix='w3c' ?>

Why don't people use UUIDs more often? What are the disadvantages of UUID namespace or advantages of a domain-based namespace? If your domain expires you might lose it and have to change all your namespaces.

Answer 1

There is no connection except by happenstance between a DNS domain name and an XML namespace.

If you have a DNS domain name and want to use it in your XML namespace, you can. If you do not have a DNS domain name or do not want to use it in your XML namespace, that is fine too.

UUIDs are not typically used for XML namespaces because they are not very meaningful - similar to typically using host & domain names over IP addresses.

Answer 2

If you want a readable, globally unique identifier that only requires you to declare ownership of a domain or email address at a point in time, you could use a tag URI. For example:

tag:user@example.com,2007-11-02:Tag_URI

A urn:uuid would be perfectly valid, but sometimes identifiers with more structure can be more discoverable, or allow for associating related namespaces.

Answer 3

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.

Email

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.