Re: [Interop] quick poll on the Translate field]

I don't have a firm opinion on source vs translate (ie: we have not
implemented it yet! :-), but I have been finding the 'source' arguments
more convincing so I am leaning that way at present. Its also what
is in the standard.

...
> So, where should the source link(s) point to? The complete solution: 
> - a raw version of the url in question
> and probably
> - a menu vonfig page, where the current menu style is choosen (or the
>   menu program module??)
> - the background gif
> - the logo, if used
> - any sub-dir logos, if used
> - possible many more resources.
> - if it's a database generated pag: possible pointers to the raw table
>   data, too.

Well, I would say logos should not be included as they are not a
part of the HTML resource (they would have separate URLs referenced
via a <IMG SRC="..."> I would assume). Since we are talking about
Web resources identified by URLs, I think including other resources
referenced by a resource (<IMG SRC=...> or <A HREF=...>) are
out of scope.

I am not sure what "possibly many more resources" would be, so I
cannot comment on them.

If its a database generated page (eg: content retrived from a database)
then I would say that is out of scope. The database is not part of
the script - it is referenced by the script.

So from your above list, we are only left with
- raw version of the URL in question (which I assume means raw version
  of the resource referenced by the URL in question)
- a menu config page, where the current menu style is chosen

> Instead, the translate header would just say: give me _this_ url,
> untranslated. No questions what this means. One resource. No choice (no
> power, too :). Easy to realize, consistent with the file system model,
> and easy to explain to the user.

So you are saying that it is not necessary to edit the 'menu config
page'? If this is the case, then the source information would only
be one URL. If you are saying its important to be able to edit
all of the resources, then you are saying the translate header is
not enough.

As I think you are arguing against the source link, I think the point
you are trying to make is that you would rather restrict the system to
have exactly one 'source' resource behind a URL--that way you can use
a 'translate' header with a single URL instead of allocating different
URLs to all of the source resources behind a URL. This makes clients
easier to write.

But you also seem to be making a case that a single source resource
behind a URL is actually insufficient, which is why there may be multiple
source values. The problem with this is it makes tools harder to
write as they have to deal with multiple sources.

Proposal:
How about introducing the concept of a single *primary* source. Simple
tools can then access that one only, whereas more powerful tools can
show the full list of sources. (Hopefully the URLs will make it clear
enough what the sources are when there are multiple of them - eg by
looking at file extensions on URLs.) To avoid changing the protocol,
the first source returned could be said to be the primary source.

If there is no such thing as a primary source, then the translate
scheme wont work correctly anyway as it is based on the presumption
that there is a single primary source for all web resources.

Alan

Received on Tuesday, 6 November 2001 20:28:55 UTC