jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jan Kuzniak (JIRA)" <j...@apache.org>
Subject [jira] Commented: (JCR-674) String properties with invalid XML characters export as invalid XML
Date Thu, 21 Dec 2006 11:36:24 GMT
    [ http://issues.apache.org/jira/browse/JCR-674?page=comments#action_12460227 ] 
Jan Kuzniak commented on JCR-674:

Hello there!

After short investigation we at Cognifide think that we know what the problem is :-)

Not only values that should be base64 are not exported, but also node and property names that
have invalid characters in it (e.g. most characters below 0x0020) are exported using entities
(that is still invalid). We are currently implementing patch for the first issue (base64).

And a little more about invalid node/property names: it seems like the difference lies between
Session.exportDocumentView and Session.exportSystemView. The first one seems to be doing it
correctly. However the second does not use ISO9075 class that is responsible for encoding.
Simply connecting exportSystemView to ISO9075 should make it (we are also going to implement

Any comments on this approach? Patch is coming soon (we hope).

 Liliana and Jan

> String properties with invalid XML characters export as invalid XML
> -------------------------------------------------------------------
>                 Key: JCR-674
>                 URL: http://issues.apache.org/jira/browse/JCR-674
>             Project: Jackrabbit
>          Issue Type: Bug
>          Components: xml
>    Affects Versions: 1.1.1
>            Reporter: Joshua Levy
> As noted in the current JCR 1.0.1 maintenance draft, sections 6.4.1,
>, XML export of string properties that contain invalid XML
> characters isn't well-defined currently, since those characters are
> not permissible in XML.  The proposed fix is to use base64
> encoding for such values in System View.
> Most characters below #x20 are examples of this.  Currently, these
> are escaped numerically in output (such as (amp)#0; )  but
> such escape sequences can't be parsed by the XML
> import methods.
> The current behavior is particularly problematic, because the user
> doesn't know the output is corrupt until later, when they try to import it
> and get InvalidSerializedDataException.
> If for some reason the base64 option is delayed, it might
> make sense, as an interim solution, to fail on export
> or to somehow patch import to relax its parsing and allow
> these escape codes.

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


View raw message