Talk:Find URI in text: Difference between revisions

::: i suppose if the url has a delimiter like quotes or <http://go.here/to this place>, then i don't see why not. it's depends on the ability to figure out the users intent. and on the application. depending on where the parser is used there might even be an opportunity to verify that a url actually exists. (now that would actually be an interesting feature: you type some text on some website, and the browser or server tells you that the url you typed does not exist)--[[User:EMBee|eMBee]] 03:38, 6 January 2012 (UTC)

 

I just had a look at this against the cited RFC. I believe the task description is inconsistent with the syntax spelled out in the RFC. For instance,

* Even though it doesn't make sense to a person "stop:" is a valid scheme and parses as a URI through 'path-empty'. To rule it out you must know what the valid schemes are.

: nothing in the task indicates that parenthesis must be balanced either. unbalanced parenthesis are certainly valid and are what the author intended too. please look at the live example i found from wikipedia: [http://en.wikipedia.org/wiki/-) http://en.wikipedia.org/wiki/-)] (and note how mediawiki parses it wrong :-).--[[User:EMBee|eMBee]] 03:57, 8 January 2012 (UTC)

:: I had another look and the RFC definitions also allow '-' and '.' in through 'unreserved', 'pchar', and 'segment' so "http://en.wikipedia.org/wiki/-)" and "http://en.wikipedia.org/wiki/-" are valid as you indicated as well as "http://mediawiki.org/).". Also the URI with the illegal character is valid up until that character so "http://en.wikipedia.org/wiki/Erich_K" is valid. Appendix C doesn't help much as none of the sample URI's are cleanly delineated. --[[User:Dgamey|Dgamey]] 04:37, 8 January 2012 (UTC)

== Expected Output Needed ==

A list of expected output should be given to avoid confusion. Some of the examples are clearly wrong.