Mailing-List: contact users-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@jackrabbit.apache.org
Received-SPF: pass (herse.apache.org: local policy)
Message-ID: <10270611.531165957451922.JavaMail.root@dell.rhoderunner.com>
MIME-Version: 1.0
From: "spamsucks" <spamsucks@rhoderunner.com>
To: <users@jackrabbit.apache.org>
References: <7840519.post@talk.nabble.com>
Subject: Re: Invalid XML characters in export
Date: Tue, 12 Dec 2006 16:04:10 -0500
Content-Type: text/plain;
	format=flowed;
	charset="iso-8859-1";
	reply-type=original
Content-Transfer-Encoding: 7bit

This is crazy, but I have been working on this issue all day (on nothing 
related to jackrabbit).

I had an error in which I am trying to transfer a String with a 0x19 
character inside it using soap (xfire, axis).  The character causes the xml 
serialization/deserialization to bomb.

I posted my problem on the xfire list:  I got this response.  While it does 
not solve your problem, I think it is related.  I am trying to "clean" my 
string data so that this does not occur.


<<
The w3 consortium's XML spec doesn't allow it, please take a look at the XML 
specification:

http://www.w3.org/TR/REC-xml/#charsets

As you can see 0x19 is not included in the 'Char' list and a XML parser 
should not accept nor generate it.

A XML conformance test suite explicitly ensures that the low (i.e. <0x20) 
characters are rejected by the parser under test.
e.g. for Xerces see: 
http://xmlconf.sourceforge.net/xml/reports/report-xerces-cnv.html
>>>


----- Original Message ----- 
From: "Joshua Levy" <levy@csl.sri.com>
To: <users@jackrabbit.apache.org>
Sent: Tuesday, December 12, 2006 3:03 PM
Subject: Invalid XML characters in export


>
> Recently I happened to create a String property containing chars
> below #x20.   The System View XML export then attempts to escape
> such values (e.g. as &#0; etc.).  However, most chars in this
> range are in fact not valid XML characters at all, so import fails
>  javax.jcr.InvalidSerializedDataException: failed to parse XML stream:
> Character reference "&#0" is an invalid XML character.
>
> Of course, binary data should be in a binary property, but
> in the event some binary does somehow get into a String property,
> it means the XML export appears to work, but is actually not usable.
>
> Is there a way to deal with this issue? I wasn't able to find
> much clarification on what the correct behavior should
> be from the spec (String properties are supposed to
> be like java.lang.Strings, but Sec 6.4.4 doesn't mention
> ways to escape non-XML characters).
>
> Regards,
> Joshua
> -- 
> View this message in context: 
> http://www.nabble.com/Invalid-XML-characters-in-export-tf2809830.html#a7840519
> Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
>