realbasic-nug
[Top] [All Lists]

Re: XML CDATA Sections

To: REALbasic NUG <realbasic-nug@lists.realsoftware.com>
Subject: Re: XML CDATA Sections
From: Charles Yeomans <charles@declareSub.com>
Date: Mon, 9 Jun 2008 16:14:49 -0400
Authentication-results: mx.google.com; spf=neutral (google.com: 74.124.194.228 is neither permitted nor denied by best guess record for domain of realbasic-nug-bounces@lists.realsoftware.com) smtp.mail=realbasic-nug-bounces@lists.realsoftware.com
Delivered-to: listarchive@realsoftware.com
In-reply-to: <FFD08B35-AAF7-4FD0-9739-6F8375F09B98@oatmealandcoffee.com>
References: <004801c8ca53$a8a151e0$6500a8c0@dave> <FFD08B35-AAF7-4FD0-9739-6F8375F09B98@oatmealandcoffee.com>
Reply-to: REALbasic NUG <realbasic-nug@lists.realsoftware.com>
Sender: realbasic-nug-bounces@lists.realsoftware.com

On Jun 9, 2008, at 3:49 PM, Philip Regan wrote:

On Jun 9, 2008, at 13:10, David Hart wrote:

The umlaut in the City element above is causing the error. If I remove umlaut, no error is raised. If the XML processor treated the CDATA section correctly, nothing in the CDATA section should be processed and should not
throw any errors.

What about changing the umlaut to an entity: &uuml;? (Unless you have some really pressing reason not to encode/decode.) Also, do you have the correct encoding declared? We've had mixed results trying to get special characters in and out of InDesign, and found that changing everything to entities resolved all of it. Even though the content maybe be wrapped in CDATA, it might still have to follow the encoding declaration.


I often find reading this version of the XML spec to be helpful.

<http://www.xml.com/axml/testaxml.htm>

Charles Yeomans

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>


<Prev in Thread] Current Thread [Next in Thread>