ISO9075

[John Crawford <cr...@gmail.com>]

Saw an issue with this the other day and wanted to pass it along to see if
it was a bug or intended functionality.
So, to encode elements in a path that begin with a number I used the encode
functionality in ISO9075.  At one point, I accidentally "over fixed" the
path by calling the encode method too many times on the path.  It actually
gave me an invalid path (it encoded it's encode).  I found this pretty easy
to reproduce as it happens in the CRX Explorer as well.

Ex:
path = /content/path/to/my/2009/08/node
path = encode( path );  // returns
/content/path/to/my/_x0032_009/_x0030_8/node/
path = encode( path );  //
returns /content/path/to/my/_x005f_x0032_009/_x005f_x0030_8/node

Again, if this is intended functionality, no worries.  Just wanted to
verify.

Respectfully,
John

Re: ISO9075

[Julian Reschke <ju...@gmx.de>]

John Crawford wrote:
> Well, the second path doesn't return results, so perhaps the issue is in the
> JCR Query/QueryManager?  It appears that its encoding the "_", which is
> apparently a valid value to query against.  So I really don't understand why
> it would encode that character.
> Either way, I'll just be careful with encoding.  :)
> ...

Encoding the path twice yields a *different* path. It's a valid path, 
but of course the query result for a different path will be ... different.

BR, Julian

Re: ISO9075

[John Crawford <cr...@gmail.com>]

Well, the second path doesn't return results, so perhaps the issue is in the
JCR Query/QueryManager?  It appears that its encoding the "_", which is
apparently a valid value to query against.  So I really don't understand why
it would encode that character.
Either way, I'll just be careful with encoding.  :)

Thanks for the response.

Respectfully,
John


On Fri, Sep 11, 2009 at 10:00 AM, Felix Meschberger <fm...@gmail.com>wrote:

> Hi,
>
> John Crawford schrieb:
> > Saw an issue with this the other day and wanted to pass it along to see
> if
> > it was a bug or intended functionality.
> > So, to encode elements in a path that begin with a number I used the
> encode
> > functionality in ISO9075.  At one point, I accidentally "over fixed" the
> > path by calling the encode method too many times on the path.  It
> actually
> > gave me an invalid path (it encoded it's encode).  I found this pretty
> easy
> > to reproduce as it happens in the CRX Explorer as well.
> >
> > Ex:
> > path = /content/path/to/my/2009/08/node
> > path = encode( path );  // returns
> > /content/path/to/my/_x0032_009/_x0030_8/node/
> > path = encode( path );  //
> > returns /content/path/to/my/_x005f_x0032_009/_x005f_x0030_8/node
>
> In what respect do you think this path is invalid ?
>
> If you encode an input, it has to encode the input. There is no way the
> method can tell, whether the second encoding is due to a programming
> error or is requested by intent. So the result of encoding agains sounds
> reasonable.
>
> Regards
> Felix
>
> >
> > Again, if this is intended functionality, no worries.  Just wanted to
> > verify.
> >
> > Respectfully,
> > John
> >
>

Re: ISO9075

[Julian Reschke <ju...@gmx.de>]

Felix Meschberger wrote:
> ...
> In what respect do you think this path is invalid ?
> 
> If you encode an input, it has to encode the input. There is no way the
> method can tell, whether the second encoding is due to a programming
> error or is requested by intent. So the result of encoding agains sounds
> reasonable.
> ...

Or, phrased differently: encoding things usually is not an idempotent 
operation. Do it once, and don't do it on things that are already encoded.

BR, Julian

Re: ISO9075

[Felix Meschberger <fm...@gmail.com>]

Hi,

John Crawford schrieb:
> Saw an issue with this the other day and wanted to pass it along to see if
> it was a bug or intended functionality.
> So, to encode elements in a path that begin with a number I used the encode
> functionality in ISO9075.  At one point, I accidentally "over fixed" the
> path by calling the encode method too many times on the path.  It actually
> gave me an invalid path (it encoded it's encode).  I found this pretty easy
> to reproduce as it happens in the CRX Explorer as well.
> 
> Ex:
> path = /content/path/to/my/2009/08/node
> path = encode( path );  // returns
> /content/path/to/my/_x0032_009/_x0030_8/node/
> path = encode( path );  //
> returns /content/path/to/my/_x005f_x0032_009/_x005f_x0030_8/node

In what respect do you think this path is invalid ?

If you encode an input, it has to encode the input. There is no way the
method can tell, whether the second encoding is due to a programming
error or is requested by intent. So the result of encoding agains sounds
reasonable.

Regards
Felix

> 
> Again, if this is intended functionality, no worries.  Just wanted to
> verify.
> 
> Respectfully,
> John
>