I agree to not allow them. I'm on windows but I always use the /. Users will have less issues if they have this habit.
Arnaud On 17/07/07, Dennis Lundberg <[EMAIL PROTECTED]> wrote:
Well, it depends, as always :) We could allow for .\ and ..\ in our own internal representation, but we cannot output those directly in our xhtml. If we do, then we are violating the RFC for URIs. They would have to be converted to / before the xhtml document is written out. Supporting both will probably end in a nightmare of strange bugs, where we always have to make sure they are converted first. IMO we should not allow it anywhere, as it encourages people to write malformed URIs. Lukas Theussl wrote: > Ok, I got it :) > > Shouldn't we still allow ".\" and "..\" as well as windows people might > use that for internal links? Or is that illegal also for links between > files? > > -Lukas > > > Dennis Lundberg wrote: >> I was caught by this one the other day as well, but didn't have time >> then to see what had gone wrong. >> >> Cabasson Denis wrote: >> >>> (I know there is a DOXIA list, but I haven't been able to find it in >>> a short time, so I used the Maven dev one). >>> >>> My problem is that on Windows, links beginning with "./", such as >>> "./link" is not interpreted as an external link (because >>> StructureSink.isExternalLink is seaching for ".\"). Thus, it is >>> rendered as href="#./link" which is troublesome. >>> And in most plugin, (like the PMD one), they are just using "./" >>> instead of bothering with the separatorChar. >> >> >> Having links that contains the \ character is plain wrong. See RFC2396 >> section 2.4.3. >> http://www.ietf.org/rfc/rfc2396.txt >> >> We should change StructureSink.isExternalLink so that it doesn't use >> File.separator. It should be using the / character directly. >> >>> Thus, this revision broke a lot of existing reports (at least on >>> Windows). >>> >>> I agree with you that DOXIA-47 is correctly fixed by this patch, but >>> it breaking quite a lot of other things, which is not good. >>> >>> Anyway, after some research, I have found that ".\link", if >>> interpreted correctly by DOXIA is not interpreted correctly by web >>> browsers (at least Opera and Firefox). >>> >>> Thus I guess a fix to this would be to change the >>> StructureSink.isExternalLink method to use "/" instead of >>> separatorChar (and repbulish a SNAPSHOT version). >>> >>> Denis. >>> >>>> -----Message d'origine----- >>>> De : Lukas Theussl [mailto:[EMAIL PROTECTED] Envoyé : mardi 17 >>>> juillet 2007 16:46 >>>> À : Maven Developers List >>>> Objet : Re: [DOXIA] Revert doxia revision 555417 >>>> >>>> (you know there is a doxia list?...) >>>> >>>> I don't quite understand your evaluation of the problem. >>>> StructureSink.isExternalLink uses text.indexOf( "." + >>>> File.separatorChar ), so this returns true for "./link" (Unix) and >>>> ".\link" (Windows). In any case you should get an external link (no >>>> #) for "./some/path/file.html". >>>> >>>> Anyway, DOXIA-47 is fixed correctly IMO, if there is a Locale >>>> problem then this is a separate issue, you should open another JIRA >>>> for that. >>>> >>>> Cheers, >>>> -Lukas >>>> >>>> >>>> Cabasson Denis wrote: >>>> >>>>> Could you please revert the Doxia revision : >>>>> http://svn.apache.org/viewvc?view=rev&revision=555417 >>>>> >>>>> And deploy a new snapshot version of doxia since latest version >>>>> (doxia-core-1.0-alpha-9-20070714.200033-13) is shipping >>>> >>>> with this patch. >>>> >>>>> This patch is breaking report created by lots of plugin. >>>> >>>> Indeed links >>>> >>>>> beginning with "./some/path/file.html" are no longer considered as >>>>> local link on my configuration (Windows with French Locale) >>>> >>>> and ends >>>> >>>>> up as links to anchor : href="#./some/path/file.html". >>>>> >>>>> This can be tracked to the fact that >>>>> >>>> http://svn.apache.org/viewvc/maven/doxia/doxia/trunk/doxia-core/src/ma >>>> >>>>> in >>>> >>>> /java/org/apache/maven/doxia/sink/StructureSink.java?revision=519803&v >>>> >>>>> ie w=markup StructureSink#isExternalLink is using File.separator to >>>>> search for relative links (which is '\' instead of '/' on windows), >>>>> while most of the report plugin are just using the '/' char (for >>>>> example, see >>>> >>>> http://svn.apache.org/viewvc/maven/plugins/trunk/maven-pmd-plugin/src/ >>>> >>>>> ma >>>> >>>> in/java/org/apache/maven/plugin/pmd/AbstractPmdReport.java?revision=51 >>>> >>>>> 70 80&view=markup AbstractPmdReport#constructXRefLocation ). >>>>> >>>>> Before revision 555417, everything was fine but with this >>>> >>>> revision, a >>>> >>>>> lots of reports are broken here, with relative links being >>>> >>>> now wrongly >>>> >>>>> considered as links to anchors. >>>>> >>>>> I guess http://jira.codehaus.org/browse/DOXIA-47 should be >>>> >>>> reopened, >>>> >>>>> and another solution found (or maybe StructureSink should be more >>>>> lenient on the separator char). >>>>> >>>>> Thanks! >>>>> >>>>> Denis. >>>>> >>>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [EMAIL PROTECTED] For >>>> additional commands, e-mail: [EMAIL PROTECTED] >>>> >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > -- Dennis Lundberg --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- .......................................................... Arnaud HERITIER .......................................................... OCTO Technology - aheritier AT octo DOT com www.octo.com | blog.octo.com .......................................................... ASF - aheritier AT apache DOT org www.apache.org | maven.apache.org ........................................................... --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
