Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Message-ID: <1109650158.1245242167817.JavaMail.jira@brutus>
Date: Wed, 17 Jun 2009 05:36:07 -0700 (PDT)
From: "angela (JIRA)" <jira@apache.org>
To: dev@jackrabbit.apache.org
Subject: [jira] Commented: (JCR-2154) Use expanded form for Path.getString()
In-Reply-To: <1121661689.1245239767682.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/JCR-2154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12720643#action_12720643 ] 

angela commented on JCR-2154:
-----------------------------

i don't have any particular feelings regarding the nature of the path delimiter used for the Path object.

but instead of changing the value of Path#DELIMITER, i would probably rather mark i deprecated and introduce
a separate delimiter constant indicating that it is valid as of version 2.0....

regarding the example:
wouldn't the result rather be

{}/{http://www.apache.org/jackrabbit/test}testPath

? 
Section 2.3.5.1  defines the expanded name to be 
ExpandedName ::= '{' Namespace '}' LocalName
which from my understanding would result in "{}" for the root node's name, wouldn't it?

> if this is too much of a change

i don't know all the details by heart... but i'd expect that the changes was limited to Path (see above) and the PathFactory implementation (-s if there are custom path and factory implementations outside of jackrabbit).


> Use expanded form for Path.getString()
> --------------------------------------
>
>                 Key: JCR-2154
>                 URL: https://issues.apache.org/jira/browse/JCR-2154
>             Project: Jackrabbit Content Repository
>          Issue Type: Improvement
>          Components: jackrabbit-spi
>    Affects Versions: 2.0-alpha1
>            Reporter: Tobias Bocanegra
>             Fix For: 2.0.0
>
>
> Currently the internal string representation of a path consists of extended path segments which are tab (\t) delimited.
> since JCR2.0, JCR input names can also be specified in an expanded form (see JCR 2.0, 3.2.5.1).
> i think it would make sense to use the expanded form also for internal string representation of paths, which is defined by the spec, is more natural and more readable 
> current:
>  {}	{http://www.apache.org/jackrabbit/test}testPath
> suggested:
>  /{http://www.apache.org/jackrabbit/test}testPath
> of course, the PathFactory needs to be backward compatible, since the path property values are persisted in the current toString() representation.
> if this is too much of a change, or if there are any valid reasons why the tab-delimited form is needed, we should at least add a new method to Path:
> String getExpandedString()
> that returns the expanded form representation of the path.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.