Mailing-List: contact user-help@ant.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Ant Users List" <user@ant.apache.org>
Received-SPF: neutral (athena.apache.org: local policy)
From: Stefan Bodewig <bodewig@apache.org>
To: user@ant.apache.org
Subject: Re: Syntax for Names: target, property, macrodef, etc.
References: <4E0C633F.2000807@sas.com>
	<BANLkTikiy1uEn8CrjcfD5wVVRP+vhga+8Q@mail.gmail.com>
	<4E15C31C.5040109@sas.com>
Date: Sun, 10 Jul 2011 18:41:30 +0200
In-Reply-To: <4E15C31C.5040109@sas.com> (Steve Amerige's message of "Thu, 7
	Jul 2011 10:30:52 -0400")
Message-ID: <87sjqem6kl.fsf@v35516.1blu.de>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

On 2011-07-07, Steve Amerige wrote:

> When I look at the 1.8.2 codebase, I see in:

>     ant-1.8.2\src\main\org\apache\tools\ant\taskdefs\MacroDef.java

>     public static boolean isValidNameCharacter(char c) {
>         // ? is there an xml api for this ?
>         return Character.isLetterOrDigit(c) || c == '.' || c == '-';
>     }

This method is indeed used to validate attribute names and names of
nested elements of tasks defined as macrodefs (but not for the taks name
itself which is not formally restricted at all).

> This seems to be at odds with the specification:

>     http://www.w3.org/TR/xml/#sec-common-syn

Quite possible, we never really targeted full conformance but somethign
I'd call "good enough".

> I've also looked at:

>     ant-1.8.2\src\main\org\apache\tools\ant\taskdefs\AntStructure.java

>         public static final boolean isNmtoken(String s) {

AntStructure is a task that has been writen ages ago to write an
approximation of a DTD for a running Ant instance (each Ant run could in
fact produce a different DTD because new elements would be added by
taskdefs).  The task has never claimed to be useful 8-)

> Maybe I'm looking at the wrong part in the code for where *element*
> names (such as macrodef and scriptdef) are validated and where other
> names (such as property name="...") are validated.

You are.

In the end the XML parser decides what is a valid name and what is not.
Ant will not stop you from creating tasks with macro/script/taskdef that
are nor legal XML element names, you will just not be able to use them
because the parser will bail out.  We do have some checks in place but
they are - as you've found out - incomplete or even wrong.

For "normal" tasks - tasks written in Java - attribute names and names
of nested elements are determined by method names and thus are way more
restricted than their XML counterparts.  You can't have a "." or a "-"
in a method name and thus can't write a task in Java with an attribute
that would contain such a character.

I don't think we have any rules on property names at all.  Same for
target names.  Beyond the restrictions the XML parser will create, that
is (obviously you can't contains a 0 character in any XML document).

Some names will put you into trouble, though.  Target names that
contains commas (quite possible we prohibit it, not sure) would be
unusable in a depends attribute of a different target for example.
Properties whose names contain "$" or "}" will be difficult to use as
well.

> But, the Ant code doesn't match what is specified by the XML BNF.

This is true.  If you feel there is a real problem, feel free to provide
a patch 8-).  The difference between the formal specification and Ant's
code is likely to be in areas that haven't caused problems in practice
(or bugs would have been reported).

> Also, the XML BNF doesn't seem to allow spaces in a *Name* object.  Is
> there an Ant BNF specification that reflects the code?

> Is there any formal specification for Ant syntax?  Where do I find it?

None that I was aware of.

> Sorry to be a bother!  But, I'm just trying to be very clear in
> understanding Ant and am hoping that a formal specification exists.

I'm afraid there isn't.  The various IDE integration projects that
support writing Ant build files may have something, but even than you
can't be sure it will contain the full truth or rather "just work in
practice".

Sorry

        Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org