Hi Michael, Thank you for your response and explanation. I will then try to filter these special signs ( ) out via an XSLT transformation or via a small Java program.
To your question:No, I didn't look at the byte sequence. How can I do this (under MS Windows)? Best regards, Lars 2008/3/12, Michael Glavassevich <[EMAIL PROTECTED]>: > > Hi Lars, > > When you say both files look the same have you actually taken a look at > the > byte sequences? If you have you'll see that there are sequences of OD OA > (CR LF) all over the place in JavaScript.java. The XInclude processor is > doing what it's supposed to do: literally including every character in the > document. > > > Thanks. > > Michael Glavassevich > XML Parser Development > IBM Toronto Lab > E-mail: [EMAIL PROTECTED] > E-mail: [EMAIL PROTECTED] > > > "Lars Vogel" <[EMAIL PROTECTED]> wrote on 03/12/2008 06:51:28 AM: > > > > Dear all, > > > > I tested this a little bit more and the behavior is different for > > different Input documents. For example for the file "index.html" the > > result is correct while for the file "JavaScript.java" the result > > not correct is. > > > > See attachment. > > > > Both files look the same. Can this be a bug? If yes, can someone > > point me to the bug database for xerces? > > > > Best regards, Lars > > > 2008/3/4, Lars Vogel <[EMAIL PROTECTED]>: > > Hi Michael, > > > > so there is no way to avoid this? Best regards, Lars > > > 2008/3/4, Michael Glavassevich <[EMAIL PROTECTED]>: > > Lars' example is doing text inclusion: > > > > > > <xi:include xmlns:xi="http://www.w3.org/2001/XInclude"; parse="text" > > href="JavaScript.java"/> > > > > > > so the XML 1.0 rules for end-of-line normalization don't apply here. The > > text in "JavaScript.java" is literally included in the document. That > > includes any carriage returns. A serializer will write those as so > > that they survive the round trip through another parse. > > > > Thanks. > > > > Michael Glavassevich > > XML Parser Development > > IBM Toronto Lab > > E-mail: [EMAIL PROTECTED] > > E-mail: [EMAIL PROTECTED] > > > > [EMAIL PROTECTED] wrote on 03/03/2008 03:29:34 PM: > > > > > > > is the carriage return character. Some systems use the > > > sequence to break lines (MS systems among others); some just > > > use (Unix systems, among others), and there are a few rare > > > cases that use something else. XML parsers are able to tolerate any > > > of these on input and will convert them all into . > > > > > > It is the responsiblity of the serializer, when the XML is written > > > back out, to decide which of these representations to use for the > > > generated XML text. In most cases it will use whatever > > > representation is native to that environment -- in our case, we ask > > > Java what the local convention is for line breaks, and we use that > > > unless a special effort is made to use something else. > > > > > > Without more details, I can't tell whether you've got that > > > misconfigured, or if whatever you're passing the generated XML > > > document to isn't handling it properly, or if something else is going > on. > > > > > > ______________________________________ > > > "... 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: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > [attachment "example.zip" deleted by Michael Glavassevich/Toronto/IBM] > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
