SV: Question regarding SearchRequest.databaseNames versus NamePlusRecord.name

Alan Kent,

The nature of your examples fit very well to the nature of the outspring for
my question.

Thank you very much, we're doing the same, I just would like to ensure, that
it's formally and/or practically correct.

Henrik Dahl

-----Oprindelig meddelelse-----
Fra: www-zig-request@w3.org [mailto:www-zig-request@w3.org]Pa vegne af
Alan Kent
Sendt: Thursday, May 09, 2002 3:55 AM
Til: www-zig@w3.org
Emne: Re: Question regarding SearchRequest.databaseNames versus
NamePlusRecord.name


On Wed, May 08, 2002 at 07:43:43AM -0400, Ray denenberg wrote:
>  But there isn't any explicit rule that the server can't supply a database
> name other than A and B. The server might, for example,  have an alias for
> "A", say "AA";  or it might supply the name of a database that is a subset
> or superset of A or B.

I have nothing technical to add to what Ray has said, but I had a
concrete example that I thought might be of interest.

We support the above (database aliases), and have found both semantics
useful. That is, sometimes you want to return the alias name, and
sometimes you want to return the database name behind the alias. We
found it depended on what the purpose of the alias was.

Sometimes our customers use an alias to build multiple small(er)
databases, possibily distributed over multiple machines. The alias
hides this fact from the user, so all records are returned as
belonging to the alias ("News" mapping onto "News.host1", "News.host2"
etc).

The other times the alias was a convent way to query multiple but
different databases. Eg: a 'newspaper' alias mapping on to 'The
Wall Street Journal' and 'The Financial Review' and 'The Herald'.
It was useful to know the database the record came from as different
formatting rules might be appropriate (for example).

So we ended up letting the database administrator choose for data
base aliases whether to return the alias name or the underlying
database name.

Alan

Received on Thursday, 9 May 2002 01:33:06 UTC