Re: Navigation Framework [was: Refactoring of document modules]

[Jörn Nettingsmeier <po...@uni-duisburg.de>]

Michael Wechner wrote:
> Josias Thoeny wrote:
>> But personally I don't think it adds much value to have multi-lingual
>> urls.
>> Or do you think it does?
>>  
>>
> 
> yes, I think so. Just think of Switzerland as a country with four 
> languages and that
> people in the french speaking part complain that the german speaking 
> part wants to rule  ....

well, from a political pov that makes sense. but from an engineering 
pov, people have always made a mess of multi-lingual uris. see for example

* punycode alternative urls. baaaaah. a half-assed solution to a real 
problem, granted. but nobody has the guts to say, ok, ditch the old dns, 
we need unicode. and nobody can answer the dreaded question: what's the 
*canonical* url? (btw, remember all the funny double-dot IIS exploits 
thanks to the uncountable number of unicode representations of "."?)

* microsoft windows. they localize system folder names (YUCK!), even 
though they are by default hidden from the user's view. how stupid can 
you get. i always use variables like %APPDATA% instead of real names, 
but guess who produces an erroneous "Application Data" folder on my 
german xp clients (where it should say "Anwendungsdaten")?
the internet exploder of one microsoft corporation. now, tell me: if 
even the original implementors screw up localized urls, who's going to 
get it right?

thus, --votes for multilingual urls. most people don't have to care 
about them anyways (you google and then click, nobody types or reads 
them anymore), so why pollute namespaces?

-- 
"Open source takes the bullshit out of software."
	- Charles Ferguson on TechnologyReview.com

--
Jörn Nettingsmeier, EDV-Administrator
Institut für Politikwissenschaft
Universität Duisburg-Essen, Standort Duisburg
Mail: pol-admin@uni-duisburg.de, Telefon: 0203/379-2736

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org

Re: Navigation Framework [was: Refactoring of document modules]

[Jörn Nettingsmeier <po...@uni-duisburg.de>]

Michael Wechner wrote:
> Jörn Nettingsmeier wrote:
>
>> well, in this case i disagree. i18n is great, but near the core, away 
>> from the user, i18n gets messy and loses its importance.
> 
> 
> do you mean the technology used or internationalization itself?

i18n itself. if done really correctly, it's a cool extra feature. i just 
don't think the trade-off between a little more l10n and the extra 
complication is worth it in things that are not really exposed to the user.

>> messy data structuring hurts the user in the long way (see the 
>> examples i gave in my previous post).
>>
>> URIs need to be systematic, and i would even prefer to have only *one* 
>> canonical URI for whatever by default, multiple UR*L*s are always 
>> compatibility hacks after the fact (and that's ok). but URIs should 
>> *not* be localized by default.
> 
> 
> why not?
> 
>>
>> they are the "book signatures" of the internet. when i go to a 
>> library, the shelves are numbered the same, regardless of the language 
>> the book is in. there is *one* dewey decimal system for catalogues in 
>> all countries. it's abstract, and thus universal.
> 
> 
> so, you mean everyone should use
> 
>     urn:uuid:4243243243223423423423
> 
> instead
> 
>     people/joern-nettingsmeier

well, it depends. people/joern-nettingsmeier is nicer to look at. but it 
gives people the wrong idea. it's just as abstract as your uuid example. 
thou shalt not tinker with system internals :)

 >> granted, URIs are nowhere near as good and systematic, and the fact
 >> that they contain letters and words can distract from the fact that
 >> they are in reality very abstract identifiers.

now show me the code that will handle "mitarbeiter/jörn-nettingsmeier" 
correctly in all cases, and yes, you will hate that "ö", because 
suddenly the url can depend on the charset of your data backend, and 
it's a world of pain. (been there, didn't touch it with a ten-foot-pole.)

something as fundamental as a resource identifier must not depend on 
such things.

>> IMHO, URIs are becoming ever less important to the end-user, since 
>> nobody ever types them anymore. so they move from "user-visible" to 
>> "internal" and can be kept generic without loss of usability.
> 
> 
> well, newspapers are starting to use them quite often to link
> their print articles with further info.
> Sure if we would have electronic paper ready, then it
> would be different ...

for that, many papers indeed have an extra url space (numbers or 
volatile textual urls).
they are ok for volatile stuff and as temporary resource *locators*. as 
*identifiers*, they mostly suck, because they are never persistent enough.

>> OTOH, having a multi-dimensional uri space makes link management 
>> harder by several orders of magnitude, and it's already non-trivial. i 
>> think the added complexity will hurt users more than abstract, 
>> non-localized urls. (besides, most of the huge international 
>> corporations do not do it either, and nobody seems to care.)
> 
> 
> well, I know a lot of people/companies who care ...
> and as said before I would argue, that if people would have
> the tools to actually manage such URL spaces, then they would
> go full steam ahead (just as my comparison with the existence of
> mobile phones and its consequences)

if it can be done correctly, fine. i just don't think it's worth the 
effort. at the moment, there are more pressing things.

>> besides, url cleanliness has never been one of lenya's strong points 
>> (it has favoured ease of implementation instead, to the point where 
>> system internals that do not concern visitors at all are exposed via 
>> the URLs).
> 
> 
> that's why we want to improve it (for better as I believe)

i appreciate that, sorry if my choice of words sounded offending.


best,

jörn



-- 
"Open source takes the bullshit out of software."
	- Charles Ferguson on TechnologyReview.com

--
Jörn Nettingsmeier, EDV-Administrator
Institut für Politikwissenschaft
Universität Duisburg-Essen, Standort Duisburg
Mail: pol-admin@uni-duisburg.de, Telefon: 0203/379-2736

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org

Re: Navigation Framework [was: Refactoring of document modules]

[Michael Wechner <mi...@wyona.com>]

Jörn Nettingsmeier wrote:

> Michael Wechner wrote:
>
>> Jörn Nettingsmeier wrote:
>>
>>> Michael Wechner wrote:
>>>
>>>> Josias Thoeny wrote:
>>>>
>>>>> But personally I don't think it adds much value to have multi-lingual
>>>>> urls.
>>>>> Or do you think it does?
>>>>>  
>>>>>
>>>>
>>>> yes, I think so. Just think of Switzerland as a country with four 
>>>> languages and that
>>>> people in the french speaking part complain that the german 
>>>> speaking part wants to rule  ....
>>>
>>>
>>>
>>> well, from a political pov that makes sense. but from an engineering 
>>> pov,
>>
>>
>>
>> I don't think the engineering pov should rule. I believe this
>> community agreed to build this stuff for end-users and not for 
>> engineers.
>
>
> well, in this case i disagree. i18n is great, but near the core, away 
> from the user, i18n gets messy and loses its importance.


do you mean the technology used or internationalization itself?

> messy data structuring hurts the user in the long way (see the 
> examples i gave in my previous post).
>
> URIs need to be systematic, and i would even prefer to have only *one* 
> canonical URI for whatever by default, multiple UR*L*s are always 
> compatibility hacks after the fact (and that's ok). but URIs should 
> *not* be localized by default.


why not?

>
> they are the "book signatures" of the internet. when i go to a 
> library, the shelves are numbered the same, regardless of the language 
> the book is in. there is *one* dewey decimal system for catalogues in 
> all countries. it's abstract, and thus universal.


so, you mean everyone should use

     urn:uuid:4243243243223423423423

instead

     people/joern-nettingsmeier

?

> granted, URIs are nowhere near as good and systematic, and the fact 
> that they contain letters and words can distract from the fact that 
> they are in reality very abstract identifiers.
>
> IMHO, URIs are becoming ever less important to the end-user, since 
> nobody ever types them anymore. so they move from "user-visible" to 
> "internal" and can be kept generic without loss of usability.


well, newspapers are starting to use them quite often to link
their print articles with further info.
Sure if we would have electronic paper ready, then it
would be different ...

> OTOH, having a multi-dimensional uri space makes link management 
> harder by several orders of magnitude, and it's already non-trivial. i 
> think the added complexity will hurt users more than abstract, 
> non-localized urls. (besides, most of the huge international 
> corporations do not do it either, and nobody seems to care.)


well, I know a lot of people/companies who care ...
and as said before I would argue, that if people would have
the tools to actually manage such URL spaces, then they would
go full steam ahead (just as my comparison with the existence of
mobile phones and its consequences)

>
>
> besides, url cleanliness has never been one of lenya's strong points 
> (it has favoured ease of implementation instead, to the point where 
> system internals that do not concern visitors at all are exposed via 
> the URLs).


that's why we want to improve it (for better as I believe)

Michi


-- 
Michael Wechner
Wyona      -   Open Source Content Management   -    Apache Lenya
http://www.wyona.com                      http://lenya.apache.org
michael.wechner@wyona.com                        michi@apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org

Re: Navigation Framework [was: Refactoring of document modules]

[Jörn Nettingsmeier <po...@uni-duisburg.de>]

Michael Wechner wrote:
> Jörn Nettingsmeier wrote:
> 
>> Michael Wechner wrote:
>>
>>> Josias Thoeny wrote:
>>>
>>>> But personally I don't think it adds much value to have multi-lingual
>>>> urls.
>>>> Or do you think it does?
>>>>  
>>>>
>>>
>>> yes, I think so. Just think of Switzerland as a country with four 
>>> languages and that
>>> people in the french speaking part complain that the german speaking 
>>> part wants to rule  ....
>>
>>
>> well, from a political pov that makes sense. but from an engineering pov,
> 
> 
> I don't think the engineering pov should rule. I believe this
> community agreed to build this stuff for end-users and not for engineers.

well, in this case i disagree. i18n is great, but near the core, away 
from the user, i18n gets messy and loses its importance. messy data 
structuring hurts the user in the long way (see the examples i gave in 
my previous post).

URIs need to be systematic, and i would even prefer to have only *one* 
canonical URI for whatever by default, multiple UR*L*s are always 
compatibility hacks after the fact (and that's ok). but URIs should 
*not* be localized by default.
they are the "book signatures" of the internet. when i go to a library, 
the shelves are numbered the same, regardless of the language the book 
is in. there is *one* dewey decimal system for catalogues in all 
countries. it's abstract, and thus universal.
granted, URIs are nowhere near as good and systematic, and the fact that 
they contain letters and words can distract from the fact that they are 
in reality very abstract identifiers.

IMHO, URIs are becoming ever less important to the end-user, since 
nobody ever types them anymore. so they move from "user-visible" to 
"internal" and can be kept generic without loss of usability.
OTOH, having a multi-dimensional uri space makes link management harder 
by several orders of magnitude, and it's already non-trivial. i think 
the added complexity will hurt users more than abstract, non-localized 
urls. (besides, most of the huge international corporations do not do it 
either, and nobody seems to care.)

besides, url cleanliness has never been one of lenya's strong points (it 
has favoured ease of implementation instead, to the point where system 
internals that do not concern visitors at all are exposed via the URLs). 
i do think that lenya's urls could use some cleaning up, but only 
towards canonicalization, not with l10n in mind. (e.g. i think the area 
is not a fundamental part of the resource, but a "view", and should thus 
be reflected in a GET parameter, not in the base URL, and so on.)


just my .02 EUR,

jörn



-- 
"Open source takes the bullshit out of software."
	- Charles Ferguson on TechnologyReview.com

--
Jörn Nettingsmeier, EDV-Administrator
Institut für Politikwissenschaft
Universität Duisburg-Essen, Standort Duisburg
Mail: pol-admin@uni-duisburg.de, Telefon: 0203/379-2736

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org

Re: Navigation Framework [was: Refactoring of document modules]

[Michael Wechner <mi...@wyona.com>]

Jörn Nettingsmeier wrote:

> Michael Wechner wrote:
>
>> Josias Thoeny wrote:
>>
>>> But personally I don't think it adds much value to have multi-lingual
>>> urls.
>>> Or do you think it does?
>>>  
>>>
>>
>> yes, I think so. Just think of Switzerland as a country with four 
>> languages and that
>> people in the french speaking part complain that the german speaking 
>> part wants to rule  ....
>
>
> well, from a political pov that makes sense. but from an engineering pov,


I don't think the engineering pov should rule. I believe this
community agreed to build this stuff for end-users and not for engineers.

Michi

-- 
Michael Wechner
Wyona      -   Open Source Content Management   -    Apache Lenya
http://www.wyona.com                      http://lenya.apache.org
michael.wechner@wyona.com                        michi@apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org