URN handling, KURL, KURI, KURN

[Frans Englich]

On Sunday 07 August 2005 04:58, Rafał Rzepecki wrote:

Hello Rafał,

Sorry for the late reply.

> I'm developing some extensions for Kontact to allow crosslinking objects
> between its components. During development I've faced a need to design an
> URI scheme to express these links, such as references to incidences or
> e-mail messages.
>
> After extensive reading of the associated RFCs, I came to the conclusion
> that URNs are much better suited for the purpose than URLs, as the
> references wouldn't express the location of the individual items, but
> rather serve to uniquely identify them, thus giving them a name.
>
> Alas, I've found that the KURL class doesn't correctly handle URNs. I've
> resorted to a crude workaround of calling KURL::decodeString() when
> handling the URNs to correct the quoting; this isn't ideal, but enough (for
> now) for my purposes.
>
> I've filed a bug for this perceived deficiency in KURL: as KURL doesn't
> only handle URLs, despite its name, but also an assorted variety of other
> URI schemes, I thought that URN should also be introduced there.
> <bug:110147>
>
> Thiago pointed me to an earlier thread regarding this issue
> <http://lists.kde.org/?t=111076322400001>, which I'd like to relate to.
> I also hope to revive active discussion on the subject.
>
> I agree that KURL class, with functionality built over during the years,
> has become a bloated, all-in-one, not-really-what-it-was-meant-to mess. I
> feel that a major cleanup of this area, in particular drawing clear
> boundaries of what this class (or its equivalent(s)) does and does not, is
> neccessary for KDE 4. I feel that all developers would benefit from a set
> of classes implementing URI-related RFCs to the letter (with particular
> exceptions for non-conformant, yet popular, schemes, such as ed2k:).
>
> I see that URNs will become important in many technologies ahead,

This is one of the areas which I think makes this topic difficult -- there are 
different opinions on what is important technologies, what kdelibs should 
contain, and so forth. For example, to mention a couple of related subjects: 
in the KURI/KURL debate there is a tendency to see URLs as the one and only; 
the KURN class was considered not of interest in kdelibs due to it being 
considered XML-specific; and the suggestion of XML/URI Guidelines(such that 
URIs/namespaces in KDE are consistent and organized) was considered not 
needed. I'm not saying that a particular opinion is wrong/right, but that 
there is a clear confusion and disagreement on what direction to take. (It 
will be interesting to see what KDE 4 will contain.)

I think people see technical problems with going for KURI/KURL separation(not 
said they're unsolvable), but I think a base KURI class would be a good idea.

> if only 
> because they are in their rationale more suited to refer to the object's
> names, rather than location, than using whatever
> k<name-your-app-here>:<some-data> schemes developers come up with.
>
> In the meanwhile, I'd be happy to see URN support integrated into KDE 3.5,
> preferably into the KURL itself, as it would make it easier to make urn:
> URIs handled correctly desktop-wise. (For example, with my application, I'd
> like to have a handler that could open incidence references from konqueror
> and, more importantly, any other application (this would be useful in many
> places, think Basket).) I don't think it's likely to break anything.
>

FWIW, if the KURN[1] class can be reused in someway(say, doing an svn external 
switch, or moving it into a central library) it would IMO be nice, for the 
usual reasons.

1.
http://websvn.kde.org/trunk/kdenonbeta/kdom/catalog/kurn.h?rev=402649&view=auto

> Another thing, I think a desktop-wide way to describe different handlers
> for different urn: namespaces, as many of these namespaces provide dispatch
> and resolution mechanisms to map them to the URLs or the actual objects.
> This could be done in the existing framework, by introducing a universal
> handler for the urn: scheme and having it dispatch appropriately, based on
> its own set of .desktop files. I am working on such limited solution right
> now, in an effort of enabling usage of my kontact references despite
> current limitations.

I agree that a uniformed approach for URI resolvers is 
needed. One case is the OASIS XML Catalog implementation which is one big URI 
resolver. When a user loads a catalog she wants it to have effect, and that's 
possible if it's globally hooked for URI resolution/rewriting.

I think it is a tricky matter because the problem space is complex. For 
example, in a case like Konqueror, ECMAScripts can install URI resolvers via 
the DOM 3 Core, meaning that the resolver mechanism must have a "final say" 
resolver(it's a security concern). Similarly, sometimes an URI *really* 
should be what it is, and not be changed. If somekind of global URI mechanism 
is implemented, questions such as "Should classes transparently use it?" and 
"If applications wants to override/disable/intervene resolution, how is that 
then done?", appears.

Regarding resolver classes, a good idea could be to have as base class DOM 3 
Load and Save's class LSResourceResolver[1](which is a URI resolver), such 
that code integrates easily with DOM/XML. It's available in KDOM, which is 
planned to be moved to kdelibs.


Cheers,

		Frans

1.
http://www.w3.org/TR/2004/REC-DOM-Level-3-LS-20040407/load-save.html#LS-LSResourceResolver