Mailing-List: contact jackrabbit-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jackrabbit-dev@incubator.apache.org
Received-SPF: pass (hermes.apache.org: domain of peeter.piegaze@gmail.com
 designates 64.233.184.196 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=AVrz1icVeA84jhYQMDTXDj+H5v5LhS4I/1mMAFcLS18Aeq5z6Rl/xNyrLrndQhiylwsxjsznq1VYyriIqF2acxLrNg1h0swq70ApZGUp1tjkY51RjJp6GvvMOgvmSvq6SBdeuuin5ai0EBRc2p0xzoelHij/UDUKq6swSlPD8Dk=
Message-ID: <3df33a2505051802244459d5e0@mail.gmail.com>
Date: Wed, 18 May 2005 11:24:24 +0200
From: Peeter Piegaze <peeter.piegaze@gmail.com>
Reply-To: peeter.piegaze@day.com
To: jackrabbit-dev@incubator.apache.org
Subject: Re: encoding jcr names
In-Reply-To: <bf35b20af35bd5c6b381e56e958531dc@gbiv.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <428A4E6B.1050701@osafoundation.org>
	 <bf35b20af35bd5c6b381e56e958531dc@gbiv.com>

On 5/18/05, Roy T. Fielding <fielding@gbiv.com> wrote:
> On May 17, 2005, at 1:04 PM, Brian Moseley wrote:
>=20
> > section 6.2.5.2 of the jcr spec (0.16.3) disallows several characters
> > in jcr names. my webdav server needs to be able to support nodes with
> > names containing at least one of these characters ("'"). what's the
> > best strategy for handling this requirement?
>=20
> That changed in the final versions of the spec.  IIRC, replace the
> character "'" with "_x0027_" (i.e., underscore x UTF-16-hex underscore).
> That's from memory, but I'm sure Peeter will correct me if I forgot
> something.  The convention is from some obscure XML NAMES standard.

Its not so much that anything changed in this department since 0.16.3.
The syntax of names and paths is the same.

The escaping mechanism Roy mentioned describes how JCR names which are
not valid XML names are mangled upon export to XML.

Brian, in your case you are going from a some webdavish resource name
and trying to produce a valid JCR name. The ugliness of the above
escaping mechanism stems from the limitations of XML. Since JCR names
do not suffer from these limitations your options for converting your
resource name to JCR are more open. Off the top of my head I don't
think URL encoding will conflict with the export to XML...or maybe you
have an example in mind?

Cheers,
Peeter