Mailing-List: contact jackrabbit-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jackrabbit-dev@incubator.apache.org
Message-ID: <1686219386.1127285203032.JavaMail.jira@ajax.apache.org>
Date: Wed, 21 Sep 2005 08:46:43 +0200 (CEST)
From: "angela (JIRA)" <jira@apache.org>
To: jackrabbit-dev@incubator.apache.org
Subject: [jira] Commented: (JCR-184) Simple Webdav: jcr-encoding for resource
 names contain invalid characters.
In-Reply-To: <1687747946.1123715435441.JavaMail.jira@ajax.apache.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

    [ http://issues.apache.org/jira/browse/JCR-184?page=comments#action_12330070 ] 

angela commented on JCR-184:
----------------------------

dealing with the encoding made it clear to me, that its wrong to use dav-resourcepath and itempath exchangeably. 
this led to some minor modifications that i would like to be commited. you could then introduce your translation as a first workaround.

> it may well be the case that this is an issue that needs to be discussed for jcr 2.0. 

a while ago i talked to peeter regarding this and he promised to put this on the issue list 2.0. i think the limitation specially for ' and " was introduced because of xml concerns but then the list is not complete. there are other characters that need encoding when building the doc-view... possibly a mistake in the spec...

regards
angela

ps: the 'translation utility' would have gone to the Text (outside webdav). but i could not think of a way to make it unambigous, in order to properly deal with itemnames/path that may be created from encoding-aware and non-aware applications. if you have a solution please let me know.

> Simple Webdav: jcr-encoding for resource names contain invalid characters.
> --------------------------------------------------------------------------
>
>          Key: JCR-184
>          URL: http://issues.apache.org/jira/browse/JCR-184
>      Project: Jackrabbit
>         Type: Improvement
>     Reporter: Brian Moseley
>     Assignee: angela
>     Priority: Minor

>
> jcr-server is a bit problematic in the way it treats the display name of a webdav resource. specifically it forces the display name to be the same as the name of the resource itself, rather than an arbitrary textual description of the resource. this is an acceptable default value for a resource's display name, but a webdav client should be able to change the display name at any point after creation of the resource.
> rfc 2518 says:
> 13.2 displayname Property
>    Name:       displayname
>    Namespace:  DAV:
>    Purpose:    Provides a name for the resource that is suitable for
>    presentation to a user.
>    Description: The displayname property should be defined on all DAV
>    compliant resources.  If present, the property contains a description
>    of the resource that is suitable for presentation to a user.
>    <!ELEMENT displayname (#PCDATA) >
> i realize that the goal of the simple webdav server is to support nt:collection and nt:file, which don't allow extra properties. that's fine; i have defined my own dav:collection and dav:resource node types on which i can add a dav:displayname property. i can then override DavResourceImpl.getDisplayName() to return the value of that property.
> the problem is that DavResourceImpl.getDisplayName() as already implemented has a couple of other purposes - calculating the resource name for a node that is about to be created and returning the resource name from an existing node.
> furthermore, both resource and display names could potentially contain characters that are illegal in jcr names. we've talked in the past about encoding these strings in order to use them as jcr names. this encoding would be necessary for the resource name (which is used as the node's name) but not for the display name (which would be persisted as a property value).
> i propose the following DavResourceImpl methods:
>   getResourceName() - returns the (unencoded) name of the resource, which is either the name of the resource's node (if the resource exists) or the final segment of the resource's uri path
>   getDisplayName() - returns the value of the resource's DAV:displayname property (if both the resource and property exist) or the string returned from getResourceName
> DavResourceImpl could simply always `return getResourceName()' as its implementation of getDisplayName(). subclasses would be free to override it to retrieve the display name from a jcr property.
> DavResourceImpl would also take care of encoding the resource name before creating the new node and decoding the resource name before returning it from getResourceName().
> thoughts?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira