Forum OpenACS Development: XoWiki URL Cleanup

a significant part of the problem is ad_urlencode, which does the encoding. The same applies for all urls, which are generated by openacs, so the correct fix for removing the spurious encoding is ad_urlencode, or even better ns_urlencode. btw, since ns_urlencode already encodes "_" as %5f (unneeded according to rfc 3986, see unreserved characters), ad_urlencode contains pre/postprocessing hacks. oacs uses a mix of ns_urlencodes and ad_urlencodes already (ns_urlencodes is used about 3 times more than ad_urlencode). I mailed about the unneeded encodings in ns_urlencode to the aolserver mailing list in dec 2005, but got no reply. in contrary to aolserver, naviserver appears to have a rfc 3986 compliant url encoder/decoder, using a different interface.

concerning 1: urlencoding uses + for spaces. this deviates from the standard. by doing so naively, one looses the ability to distinguish between "a b" and "a_b". Is there a specification, what mediawiki does in detail?

concerning 2: notice that RFC 1738 was replaced by RFC 3986, which says: for "unreserved characters", defined as

unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"

no percent-encoded octets should be created. URIs that differ in the replacement of an unreserved character with its corresponding percent-encoded US-ASCII octet are equivalent: they identify the same resource.

concerning 3: what is the connection between content negotiation and language selection in xowiki? what is your exact proposal?

i am open to discuss every change proposal, but strictly against hacks.

ad_proc oacs_dav::urlencode { string } {
    urlencode allowing characters according to rfc 1738
    http://www.w3.org/Addressing/rfc1738.txt

    "Thus, only alphanumerics, the special characters "$-_.+!*'(),", and
    reserved characters used for their reserved purposes may be used
    unencoded within a URL."

    ignore + used to encode spaces in query strings

    This is mainly to support MS Web Folders which do not follow the
    spec which states that any character may be urlencoded. Web Folders
    rejects the entire collection as invalid if a filename contains
    one of these characters encoded.
} {
    set encoded_string [ns_urlencode $string]
    set encoded_string [string map -nocase \
                            {+ %20 %2d - %5f _ %24 $ %2e . %21 ! %28 ( %29 ) %27 ' %2c ,} $encoded_string]

   return $encoded_string
}

its not pretty but it works. Perhaps we should add this to acs-tcl as ad_urlencode until AOLserver is fixed.

I am pretty sure I discussed this on the AOLserver list or in email with AOLserver folks back when I did the tDAV work and never got any resolution. ns_urlencode has been overly agressive forever.

set subst_blank_in_name 1

after some testing, we could make it the default behavior, if there is interest and not too many negative gotchas for this.

Here is what I did:

1. Made the change
2. Created a new page named "new page"
3. Linked to that page using [[new page]]

Here is what happened:

1. new page was created as "new_page"
2. link points to "new+page"

Carl's item 3 above, "language to be determined using content negotiation", is the only part whose design and implementation in OpenACS seems unclear so far, and probably needs discussion.

(I haven't actually worked with XoWiki yet, so the below may be ignorant of any related features it already yes...)

This language negotion thing sounds like a good approach, if it works. The major caveat I'd make is that regardless of whether language negotion succeeds or fails, it should always be possible for the user to see the other languages/versions of that document available, explicitly select an alternate version, send others a link to either the specific document/language URL or the generic URL, etc.

In other words, the language negotion should give the most reasonable default, but the user should always have the option of easily taking over explicit control, by simply clicking on the appropriate links. If a user uses the generic URL, and gets the German version via language negotion, he should always be able, via some website UI, to see that there are also English and Spanish versions available, and explicitly access those specific versions if he so chooses.

Note, this is entirely separate from telling the website, "No, I don't want any German docs from you, please change my site-wide preference to English." The user should also be able to do that, but that should be mostly orthogonal to the per-item access I'm talking about above.

After all, a user may prefer German as his default, but want to read the original English version of a specific document, email the URL of the Spanish version to a colleage saying, "Heh, I think the translator mis-translated paragraph 8 of our paper, but my Spanish is rusty, what do you think?", etc.

If my preferred version (by whatever method) is Germans, or English, or Spanish, should it show me the correct version, with the "official" url for that language, so if I share it, it shows the url of the language I am looking at, or a "generic" url that automatically shows me some version.

This is tricky, b/c then if I explictly choose another language, i'll get the language specific URL, but it makes it hard to copy/paste the language specific URL for my preferred language.

So there are two options 1) generic URL that auto selects, and 2) redirect to the correct language specific URL. I have no idea which is better or why, but I think there an be a case made for both.

Perhaps someone who has done someting with multi-language content can comment, I know greenpeace.org has multiple language content, but I don't know how they do it.