ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Richardson <>
Subject Re: antstructure task
Date Tue, 12 Jun 2001 13:47:29 GMT
Stefan Bodewig wrote:
> Eric Richardson <> wrote:
> > I use emacs with psglms as an XML editor.
> XEmacs here, but otherwise I know what you are talking about.
> > That might be a very nice enhancement - just call the parser in
> > validating mode?
> The problem with the "DTD" antstructure generates is - it is not a DTD
> for valid build files.  The extensibility of Ant renders this
> impossible, as DTDs are too restricted.

Do you mean that people would have a hard time extending a dtd for a new
task or that a ant build file does not conform to a DTD? 

It seems that if certain tasks, attibutes etc are supported with certain
nestings by the ant engine or the task itself then that is the defacto
DTD. Therefore the ant could call the parser with validating mode and
catch problems before the runtime checks are done. I'm not saying that
the validating has to be required but could be an option. Certainly, a
validated file would reduce code bulk as the system/components would not
have to check for inconsistencies. Wouldn't it at least work for core

> The main problem is, that people writing tasks can define their own
> nested elements (which is good) and may choose names for these nested
> elements that have been used in some other context as well (which is
> not bad, but violates a possible DTD).

They would have to know how to extend the dtd properly.

> Take <test> for example.  There is an optional task by that name with
> an element definition like this:
> <!ELEMENT test (arg | jvmarg | classpath | sysproperty | testlet)*>
> and a nested child of <junit> which would be

Are you getting at namespaces here? If junit is ju then this could be
<!ELEMENT ju.test EMPTY>
so that it doesn't conflict with the prior definition? This of course is
a dtd fixed namespace hack AFAIK.

> The real solution is to switch to XML Schema here.  Extending
> antstructure to support XSD is on the agenda, but I guess it will take
> some time - as well as it will take time for the tools (including
> PSGML) to support XSD.

Definitely bleeding edge and the jury is still out I would suppose.


View raw message