Custom URI schemes & KDE

Frans Englich frans.englich at
Mon Jan 9 23:27:47 GMT 2006

On Sunday 08 January 2006 17:36, David Faure wrote:
> Please make sure to state in the document that those uri schemes are
> for e.g. XML documents and applications, rather than for KIO [which uses
> something like a prefix rather than a full namespace, in fact, in the xml
> sense].

I previously added:

However, due to the usability requirements KDE in some cases have, there can 
be circumstances where a “rogue” scheme(such as media://) makes sense. 
Carefully consider(discuss, seek peer review) before going for an invalid URI 
scheme, and if so, ensure technical measures are done to lower the risks of 

which to me looks like the required loop hole(for exercise in KIO, or anywhere 
else). Honk if it's insufficient.

> If we're talking about XML, then what's the problem with doing it using
> w3c-like urls? For instance in the OpenDocument support in KOffice, when we
> need to add an attribute or element that is specific to koffice, we use the
> "koffice:" prefix, and it maps to the following namespace:
> This could very well be ",2005:KOffice:OpenDocument" instead,
> which indeed looks a bit more like OpenDocument's own namespaces like
> "urn:oasis:names:tc:opendocument:xmlns:office:1.0"
> (Any reason why we should use tag: instead of urn:? Just wondering what's
> the difference)

Here's the main differences between tag and urn that comes to my mind:

* How they are allocated. For tag, one needs a domain name(or email address) 
in order to be able to create a unique URI. With urn, one basically have to 
write an RFC(for example, RFC 3121 covers urn:oasis:*).[1]

* Syntactically, URNs are more constrained than tag URIs. URNs are like "only 
identifiers", they house a name, while tag can use the full range of URI, 
constructs like fragments("#") and query parts("?"). Using a fragment would 
be invalid in a URN.

So, it depends on what one needs(whether the constraints of URN is ok), and 
whether one have a URN namespace(urn:myUrnNamespace:*). 

> Sorry for bringing KIO into the discussion. It was certainly a bad example
> of where to apply such uri schemes; in particular because user-friendlyness
> matters there (so short prefixes are needed), unlike in XML documents.
> I agree with the use of tag: urns in xml documents, if you're saying this
> is the recommended way. Too late for koffice though :(

Personally speaking, I wouldn't worry, I find http URIs fine for XML 
namespaces. When I researched stuff like this my impression was that this is 
rather debated. Here's the pros/cons I can think of:

* URNs for namespaces makes sense, conceptually. A namespace doesn't identify 
a file, it's just a unique string which groups names(it's a namespace ;-)). 
In this regard http are a bit off. This point is nicely illustrated by the 
question "Why does result in a 404?". 

* However.. there's RDDL[2]. The idea is that one puts an RDDL file at a http 
namespace's location. That file describes the namespace. For example, this 
makes it possible to programmatically locate a schema for an arbitrary XML 

That two major XML related standardization organizations, OASIS & W3C, are 
using http and urn, respectively, I'd say shows neither alternative can be 
completely wrong.

If somewhere in KDE an XML namespace is needed, what would one choose? Use 
"*" or ",2004:theApp:*"? I think it 
depends. Using tag is now cheap with little impact, one just adds the app to 
the table in the URI document and the app can do whatever it wants. Usages 
involving are harder to get rid of and ties the domain. As a 
quick thought, I would use for kdelibs technologies, and let,2004 be used for arbitrary apps(which potentially has short life 


There's also some other ways of gettings URNs without writing an RFC. One can 
use "urn:fdc" which is almost exactly as tag(just replace "tag:" with 
"urn:fdc", basically). That is, it's by the same principle of tag(use a 
domain + date to get a unique URI) but is a URN instead. One can also very 
easily request an "informal URN namespace" which is "urn:urn-X:", such as 


More information about the kde-core-devel mailing list