Custom URI schemes & KDE
frans.englich at telia.com
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
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 "tag:kde.org,2005:KOffice:OpenDocument" instead,
> which indeed looks a bit more like OpenDocument's own namespaces like
> (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:*).
* 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 http://www.kde.org/standards/kcfg/1.0/ result in a 404?".
* However.. there's RDDL. 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
If somewhere in KDE an XML namespace is needed, what would one choose? Use
"http://kde.org/standards/*" or "tag:kde.org,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 http://kde.org are harder to get rid of and ties the domain. As a
quick thought, I would use http://kde.org for kdelibs technologies, and let
tag:kde.org,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