Frans Englich frans.englich at telia.com
Mon Mar 14 01:27:34 GMT 2005


I'm working on an OASIS XML Catalogs[1] implementation, and for that I need 
support for the URI type URNs[RFC 3151], in particular the publicid 
namespace[RFC 2141].

The attached patch is a "KURN" class with accompanying test cases, which it 
passes. AFAICT, it is feature complete and covers everything which is needed 
for a Catalog implementation, for example. I would preferrably see URN 
functionality in kdecore.

While I'm just fine with the attached class for my needs, I suspect it doesn't 
play well with kdecore/KURL, whose design I'm a bit confused by. KURL handles 
URL functionality, /plus/ its superset URI. By that principle any URI 
functionality such as URN should be put in KURL, which is quite illogical, 
IMO. I find that design non-oop, and too broad, since for example both URN 
and publicid is rarely used functionality. So, the different functionalities 
are "multi-plexed" in KURL instead of factoring it in classes, but by that 
principle the class should have been named KURI, IMHO. 

What are the plans for KDE 4? To split KURL into KURI and KURL? The Catalog 
implementation will live in kdenonbeta/kdom and hence first becomes relevant 
for KDE 4, so I can live with a temporary solution, such as housing the class 
there, or to (preferrably) have it in kdecore/, inherting KURL as it does 
now. It's nice functionality afterall.

Also, the patch itself needs sanity-reviewal, I don't know where I should rely 
more on KURL, if the decode/encode loops are correctly approached, etc. 

In other words, some clear answers are needed :)




The specification:

An user oriented overview:
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kurn.diff
Type: text/x-diff
Size: 22687 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20050314/731fd7d4/attachment.diff>

More information about the kde-core-devel mailing list