You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ddlutils-dev@db.apache.org by "Michael Lipp (JIRA)" <ji...@apache.org> on 2008/03/02 17:24:50 UTC
[jira] Created: (DDLUTILS-196) Text data dumped incorrectly
Text data dumped incorrectly
----------------------------
Key: DDLUTILS-196
URL: https://issues.apache.org/jira/browse/DDLUTILS-196
Project: DdlUtils
Issue Type: Bug
Components: Core (No specific database)
Affects Versions: 1.0
Environment: Any
Reporter: Michael Lipp
Assignee: Thomas Dudziak
DdlUtils does not properly preserve content through a dump/restore cycle if the content contains newlines.
DdlUtils takes the following approach for dumping text content:
(1) Write as value attribute, unless it cannot be written as such
(2) Write as "plain" element content unless it cannot be written as such
(3) Write as CDATA unless it cannot be written as such
(4) Write uuencoded.
Now when can a value not be written as attribute value? Easy: when there is no valid representation that reads back the same value. And here is the problem. The XML recommendation specifies something called "attribute value normalization" (http://www.w3.org/TR/xml/#AVNormalize). Due to this, white space characters except space (#xD, #xA, #x9) in attribute values are not read back in the same way as they are written.
There are two ways to circumvent this: (a) write them as character references (e.g. 
) or (b) skip to method (2). Option (a) cannot be used here , because it is impossible to write a "&" in an attribute value when you use XMLStreamWriter. The spec says: 'However the writeCharacters method is required to escape & , < and > For attribute values the writeAttribute method will escape the above characters plus "' (http://java.sun.com/webservices/docs/1.5/api/javax/xml/stream/XMLStreamWriter.html). You might expect that the XMLStreamWriter.writeAttribute should handle escaping of the whitespace characters (#xD, #xA, #x9), but if you read the spec carefully it does not say so. Leaves option (b).
The attached patch fixes this problem.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DDLUTILS-196) Text data dumped incorrectly
Posted by "Michael Lipp (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DDLUTILS-196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Michael Lipp updated DDLUTILS-196:
----------------------------------
Attachment: patch.txt
This patch is against 1.0.
Note that I have separated the decision if value can be written as an attribute from the decision whether it requires uuencoding (the criteria are really different).
> Text data dumped incorrectly
> ----------------------------
>
> Key: DDLUTILS-196
> URL: https://issues.apache.org/jira/browse/DDLUTILS-196
> Project: DdlUtils
> Issue Type: Bug
> Components: Core (No specific database)
> Affects Versions: 1.0
> Environment: Any
> Reporter: Michael Lipp
> Assignee: Thomas Dudziak
> Attachments: patch.txt
>
>
> DdlUtils does not properly preserve content through a dump/restore cycle if the content contains newlines.
> DdlUtils takes the following approach for dumping text content:
> (1) Write as value attribute, unless it cannot be written as such
> (2) Write as "plain" element content unless it cannot be written as such
> (3) Write as CDATA unless it cannot be written as such
> (4) Write uuencoded.
> Now when can a value not be written as attribute value? Easy: when there is no valid representation that reads back the same value. And here is the problem. The XML recommendation specifies something called "attribute value normalization" (http://www.w3.org/TR/xml/#AVNormalize). Due to this, white space characters except space (#xD, #xA, #x9) in attribute values are not read back in the same way as they are written.
> There are two ways to circumvent this: (a) write them as character references (e.g. 
) or (b) skip to method (2). Option (a) cannot be used here , because it is impossible to write a "&" in an attribute value when you use XMLStreamWriter. The spec says: 'However the writeCharacters method is required to escape & , < and > For attribute values the writeAttribute method will escape the above characters plus "' (http://java.sun.com/webservices/docs/1.5/api/javax/xml/stream/XMLStreamWriter.html). You might expect that the XMLStreamWriter.writeAttribute should handle escaping of the whitespace characters (#xD, #xA, #x9), but if you read the spec carefully it does not say so. Leaves option (b).
> The attached patch fixes this problem.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DDLUTILS-196) Text data dumped incorrectly
Posted by "Michael Lipp (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DDLUTILS-196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Michael Lipp updated DDLUTILS-196:
----------------------------------
Attachment: patch-updated.txt
Updated the patch. Actually, this should be reported as an independent bug, but why make things unnecessarily difficult.
When analyzing the text, the method stops (i.e. returns true) when a really special character is found. It shouldn't do so if cutPoints are to be reported as well, because there may be cut points after the first really special character encountered!
> Text data dumped incorrectly
> ----------------------------
>
> Key: DDLUTILS-196
> URL: https://issues.apache.org/jira/browse/DDLUTILS-196
> Project: DdlUtils
> Issue Type: Bug
> Components: Core (No specific database)
> Affects Versions: 1.0
> Environment: Any
> Reporter: Michael Lipp
> Assignee: Thomas Dudziak
> Attachments: patch-updated.txt, patch.txt
>
>
> DdlUtils does not properly preserve content through a dump/restore cycle if the content contains newlines.
> DdlUtils takes the following approach for dumping text content:
> (1) Write as value attribute, unless it cannot be written as such
> (2) Write as "plain" element content unless it cannot be written as such
> (3) Write as CDATA unless it cannot be written as such
> (4) Write uuencoded.
> Now when can a value not be written as attribute value? Easy: when there is no valid representation that reads back the same value. And here is the problem. The XML recommendation specifies something called "attribute value normalization" (http://www.w3.org/TR/xml/#AVNormalize). Due to this, white space characters except space (#xD, #xA, #x9) in attribute values are not read back in the same way as they are written.
> There are two ways to circumvent this: (a) write them as character references (e.g. 
) or (b) skip to method (2). Option (a) cannot be used here , because it is impossible to write a "&" in an attribute value when you use XMLStreamWriter. The spec says: 'However the writeCharacters method is required to escape & , < and > For attribute values the writeAttribute method will escape the above characters plus "' (http://java.sun.com/webservices/docs/1.5/api/javax/xml/stream/XMLStreamWriter.html). You might expect that the XMLStreamWriter.writeAttribute should handle escaping of the whitespace characters (#xD, #xA, #x9), but if you read the spec carefully it does not say so. Leaves option (b).
> The attached patch fixes this problem.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.