Hi David(s) !
=>=To what end? Is the purpose of the database registration information
=>=lookup or a more general white pages service? I' would suggest the
=>=former and leave the latter to the WHOIS++/LDAP/X.500 crowd.
What's the *inherent technology* difference between a registration
lookup and a general white pages service?
Sure, ultimately the number of entries...
As soon as we have a production environment with these tools (both from
technology, software, coverage, logistics and web access) I'll be happy
to move ;-)
==>
==> - local langauge problems (European National Character Sets) which make
==> it difficult to find out about a (arbitrarily chosen) transcription.
=
=Local language problems? Heh. Let me introduce you to traditional
=Chinese with all 100,000+ characters :-).
Thank you. For the time being I just (have to) appreciate them as a
piece of art.
Unfortunately I lack the time to dive into that to the degree I would
like to master. But if there is any special consideration of
transcribing these letters (well, more local language independent
symbols?) into 7bit ASCII for a DB I'd be happy to be clued in.
What I was primarily referring to is the 7bit transcription of European
local languages for "funny" characters. While I don't know about other
countries, e.g. I'm perfectly aware that even *within the German
region*, there is differences in defined transcriptions:
AT (and DE?) a "sharp s" is formally written as "sz" but
usually we use the "ss" form in everyday
transactions.
CH the same is written as "ss"
For Scandinavia there is a couple of different umlauts with double
dots, crossing an "o" or ligatures, etc.
Do you reaaly know about the transcription?
=> The advantage of the whois
=>database serving as a simple registered object lookup mechanism is
=>that you don't have to worry (too much) about gunk like local language
=>support -- the registration database access method (whois) allows
=>lookups on registry objects, namely inetnums, handles, domains, route
=>objects, etc. of which people (generally :-)) are not a part.
Then I don't understand why we have the recursive lookup for person
objects...
=Yes, I'm arguing person: field contents should not be indexed, but
=I've been known as a radical in the past. Note this would have
=solved the problem that brought this issue up (I think).
Well, reality differs.
Those of us who have to work with end-users have to process a lot of
requests that involve dealing with person objects. Whether they are
directly indexed or just referenced doesn't make a big difference.
I want to find out whether some guy or gal is already in the DB - full
stop. And it's more comfortable to do that with a wildcard replacing a
"sharp s" or an umlau than being "radical" and try all the different
possibilities that I can imageine.
=> - comments from other environments, where the lack of this feature was
=> quoted as a major obstacle to use this software 'cause this
=> functionality is provided right now.
=
=If all you have is a hammer, everything begins to look like a nail.
=This doesn't mean you should attach a blender to your hammer to allow
=making more consistent puree...
Thank you :-)
I just wonder why you need a blender when you've got a hammer?
Just kidding :-)
Wilfried.
--------------------------------------------------------------------------
Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at
Computer Center - ACOnet :
Vienna University : Tel: +43 1 4065822 355
Universitaetsstrasse 7 : Fax: +43 1 4065822 170
A-1010 Vienna, Austria, Europe : NIC: WW144
--------------------------------------------------------------------------
