Mailing-List: contact dev-help@ant.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Ant Developers List" <dev@ant.apache.org>
Received-SPF: pass (nike.apache.org: domain of latchkey@gmail.com designates
 74.125.83.173 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:from:date:message-id:subject:to
         :content-type;
        b=ASIhO9EwAS6ylD7Bf5tKEy/iocgLLHdU9SalQW6ilhp/mYmWzT+arwxzJvDWr509R7
         dwrBNb5n7hi/bEV0mQix178W8KSp4docI4cditbPNdkvP9PqCOHW2/NGtumpje5EFHX4
         3S3HgfjrAwwQ2vF6gpb+ucMw5O7WRraxwcXDM=
MIME-Version: 1.0
In-Reply-To: <AANLkTin02AfNbgqFKgXki_bevbldOOPiv7m-L5sOkY3L@mail.gmail.com>
References: <AANLkTikh98bijUxc7mg-c2uGt912dCIW-XwkE5rTbtxF@mail.gmail.com>
	<AANLkTinFUZ0beWGJGscVFDmUrPqNcoMpWVI-BkhHLAvK@mail.gmail.com>
	<4C264FE4.1050007@gmx.de>
 <AANLkTikOQomiu-G_AXybBMsUZK6LVyd3xDZBBxykoIPU@mail.gmail.com>
	<AANLkTin02AfNbgqFKgXki_bevbldOOPiv7m-L5sOkY3L@mail.gmail.com>
From: Jon Stevens <latchkey@gmail.com>
Date: Sun, 27 Jun 2010 18:55:00 -0700
Message-ID: <AANLkTimQY_xGIESB9gB6CPtb1SN8SSs8tDhXEoyxMJUN@mail.gmail.com>
Subject: Re: bug in DOMElementWriter
To: Ant Developers List <dev@ant.apache.org>
Content-Type: multipart/alternative; boundary=001636458388c07d90048a0d69bd

--001636458388c07d90048a0d69bd
Content-Type: text/plain; charset=ISO-8859-1

On Sun, Jun 27, 2010 at 10:35 AM, Dominique Devienne <ddevienne@gmail.com>wrote:

> On Sat, Jun 26, 2010 at 6:54 PM, Jon Stevens <latchkey@gmail.com> wrote:
> > For example, attr="&amp;" comes out as attr="&amp;" and not attr="&"... I
> > don't have to write attr="&amp;amp;" to get what I want. The same is true
> > with attr="&gt;"... it comes out as attr="&gt;" instead of attr=">". This
> is
> > all because DOMElementWriter.encode() is smart about those entities.
> >
> > attr="&#10;" should come out as attr="&#10;", not attr="\n"
>
> Well, I'm afraid Antoine is right, and the comparison you make is not
> "fair".
>
> &, <, and > are "special" in XML, and must always be encoded in
> attribute values and textual content. \n is not.
>
> <echoxml> never sees the "&amp;" text, it sees whatever the XML parser
> reports, a "&", and the XML serializer Ant uses knows it must encode
> that char into "&amp;", thus it ends up back the way it was. But with
> \n, which is just like any other character*, the serializer doesn't do
> anything special, and the output the also contain a "plain" \n.


However, the character that went into the attribute was not a \n, it was a
&#10;. I'd expect ant to give me &#10; back out, not \n. The point of
<echoxml> is to echo xml, is it not? In that case, the point here should be
to echo out the encoded value as xml, not something that is useless.

jon

--001636458388c07d90048a0d69bd--