Re: policy question on URI specs (from sms: discussion)

Hello Larry, Erik, others,

Looking at Erik's lecture notes, and at
http://h3h.net/2007/01/designing-urls-for-multilingual-web-sites/
linked from there, I have to in general agree with Larry, but I
definitely wouldn't want to make this a policy question, more
a matter of good design.

At the above URI, Erik writes: "The w3c publishes all kinds of documents
about how to use markup to identify languages, but as far as i can see
is silent on the issue of how to design uris for multilingual resources."

This is true, and I guess I'm to some extent responsible for this.
Providing some overview (here are the various different ways to do
this) in some outreach material would make a lot of sense, and
maybe this already has been done; I'm cc'ing Richard Ishida,
who now leads the I18N Activity and in particular the related
outreach efforts at W3C.

However, it would be/have been a very bad idea for the W3C
to come up with "THE" way to encode language into URIs.
Different content providers have different needs. Using different
TLDs, different lower level domain labels, extensions, path
components, or whatever all depend on various technical
(what server you use,...) and operational issues. The best
solution is to use language negotiation for the problem of
providing different language versions of the same document
(in cases where parallel versions actually exist; often,
the whole Web site might be totally redesigned for a different
language/culture/market).

Also, once you start with language, there is no limit to other
parameters that one might want to include in an URI. A rathole.

Regards,   Martin.

At 23:17 07/09/21, Larry Masinter wrote:
>
>In a lengthy off-list discussion of 
>
>       http://tools.ietf.org/html/draft-wilde-sms-uri-12  
>
>we came to what seemed to me to be a policy question of whether URI schemes 
>are better off defining all of the options one might want to use (in this 
>case, the telematic interworking specifications) or to intentionally limit 
>the syntax to things that can be trusted to be implemented by most all 
>interpreters.  
>
>I thought I would raise the more general policy issue on the URI list. 
>(Excerpts from conversation below).
>
>
>[Larry]
>> I'm starting to think that it would be better to leave out all the extra 
>signaling stuff that someone *might* want to say, and instead just have a 
>simple scheme:
>>    sms:<telephonenumber>
>> and don't define anything else. It would be simple, straightforward, 
>secure, and interoperable. It's OK if there's no way of signaling other 
>features that won't be widely implemented anyway.
>
>[Erik]
>that would remove half of the spec....  not that that is out of the  
>question, and you are definitely right that in most cases the telematic 
>interworking will not be supported ... maybe there are scenarios where 
>telematic interworking is still required. i used it quite a lot when phones 
>still supported it somewhat, but now most phones don't support it at all, 
>so it is hard to use, even if you want to.
>
>[Larry]
>
>> (There's no way to signal HTTP request headers in http: URIs for example. 
>It's OK. It would be a bad idea to add a lot of decoration to add it. The 
>request headers are up to the client.)
>
>[Erik]
>...  i actually think that it would be better to have some well-defined 
>interaction between http uris and the protocol mechanics. 
>http://dret.net/lectures/publishing-spring07/i18n+l10n#(30) is one good 
>reason for this, the inability to create a uri for selecting a variant of a 
>content negotiated resource is something that keeps people from setting up 
>well-configured internationalized web servers. i don't see why that would 
>be a bad thing, on the contrary, i think it would be a very good thing, but 
>i also see that it is not going to happen.
>
>think of location-negotiated resources. let's say i want to identify the 
>resource with berkeley's movie program. with well-designed interaction of 
>uris and http, i could say http://movies.com/program;location=berkeley


#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:duerst@it.aoyama.ac.jp

Received on Thursday, 4 October 2007 07:56:18 UTC