Actually, 
 or are technically "numeric character references", not entity references. Check the spec, but if I'm remembering the whitespace rules correctly, these may get converted early enough not to help in this case. You may need an actual &CR; entity defined in the DTD.
______________________________________ "... Three things see no end: A loop with exit code done wrong, A semaphore untested, And the change that comes along. ..." -- "Threes" Rev 1.1 - Duane Elms / Leslie Fish ( http://www.ovff.org/pegasus/songs/threes-rev-11.html) Paul Gearon <gea...@ieee.org> Sent by: gea...@gmail.com 03/02/2009 01:36 PM Please respond to j-users@xerces.apache.org To j-users@xerces.apache.org cc Subject Re: carriage return in attribute I'm not saying that this is the answer to your problem, but the entity referred to here is: 
 Paul On Mon, Mar 2, 2009 at 12:20 PM, Aleksandr Kravets <akravets.w...@gmail.com> wrote: > Ok, I think I found an issue similar to mine, it is in this thread: > http://www.stylusstudio.com/xsllist/200404/post40600.html > > Particular line of interest to me is this: > > "BTW, if you want your attribute to have a carriage return, you can use an > entity to express the carriage return, then it doesn't get normalized." > > So can someone explain what this means and how do I describe these entities? > May be I can insert them into XML before importing and letting parser do its > work? > > thanks, > Alex > > > > On Mon, Mar 2, 2009 at 12:26 PM, Aleksandr Kravets <akravets.w...@gmail.com> > wrote: >> >> Totally agree, but even if originating XML is corrected, there are clients >> with wrong style XML that will use my application to import XML and in such >> a case there is little I can do. So, is there a way to correct this problem >> during the import? >> >> Thanks for your help, >> Alex >> >> On Mon, Mar 2, 2009 at 12:21 PM, <kesh...@us.ibm.com> wrote: >>> >>> The purpose of an XML parser is to read correct XML. Get whoever's >>> generating that file to produce XML that expresses their intent >>> correctly, >>> or throw in a filtering stage that corrects their error. Personally, I >>> would apply a clue-by-four to the author of whatever's generating that >>> document rather than trying to tolerate it, since they're just going to >>> get themselves in deeper trouble later... but I understand that this >>> isn't >>> always possible. >>> >>> "The customer isn't always right. Unfortunately, the customer is always >>> the one with the money." >>> >>> ______________________________________ >>> "... Three things see no end: A loop with exit code done wrong, >>> A semaphore untested, And the change that comes along. ..." >>> -- "Threes" Rev 1.1 - Duane Elms / Leslie Fish ( >>> http://www.ovff.org/pegasus/songs/threes-rev-11.html) >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: j-users-unsubscr...@xerces.apache.org >>> For additional commands, e-mail: j-users-h...@xerces.apache.org >>> >> > > --------------------------------------------------------------------- To unsubscribe, e-mail: j-users-unsubscr...@xerces.apache.org For additional commands, e-mail: j-users-h...@xerces.apache.org
