ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Loughran <>
Subject Re: String -> Ressource (was Re: archivefileset resources)
Date Fri, 23 Mar 2007 15:39:21 GMT
Matt Benson wrote:
> --- Steve Loughran <> wrote:

> Maybe.  :)  But really, I appreciate your input.  I
> have no problem admitting how clueless I am wrt xml in
> general and ns in particular.  :|

rule 1 of xml: nobody understands XML namespaces
rule 2: anybody who says they do. still doesnt.

so there are the following categories

-ignorant of xmlns
-vaguely aware, but doesnt understand
-think they understand,  but doesnt really
-knows xmlns enough to know it doesnt make sense, and doesnt understand

if you meet someone who thinks they do understand it, ask them if, in 
xml schema, the ##local namespace is in ##other, or not.

For the record, I know enough for them to scare me, that's it.

>> have had to deal with 
>> exactly this kind of problem in the past, where we
>> really did have to 
>> extract and maintain the xmlns list. And believe me,
>> Xom does not go out 
>> of its way to make that easy
> Can we mitigate any of this with usage guidelines? 
> Three ways to resolve a type, the first two of which
> are easy:
>  - use a type in a globally defined ns
>  - use e.g


 >  - use a type in a globally defined ns

kind of breaks some of the xmlns rules

 >  - use e.g

this is somewhat similar to how XPath lets you insert new XMLNS 
declarations. If you were do it, I'd prefer

{}type as that is equivalent to how 
javax.xml.QName.toString() works

> third option would require awareness of available
> namespaces at the time of resolution, so if you
> defined
> <property name="resource" value="myns:type?blah" />
> you'd have to say:
> <echo output="${resource}"
> xmlns:myns="antlib:org.myorg" />
> or whatever... does that solve and/or accomplish
> anything?

it would certainly work, but be unduly painful. Your task would need to 
know which namespace declarations to put i for a resource, which then 
becomes something you can't change.

Other options

-make a QName an official Ant type. When you set it, the XMLNS gets 
expanded. This is a good idea anyway; too bad QNAme is only built in to 
java5, though javax.xml.namespace is available as an add-on for older code.

you could create one in the qname task
<qname ns="http://org.example/" local="local" >   == 
<qname local="local" > == {}local
<qname ns="something" > == BuildException no local
<qname value="prefix:value" > == {lookup(prefix)}value  ... xmlns:prefix 
would have to be up the tree

Of course, this doesnt help you with the problem of defining resource 
destinations in a string, or a properties file...

-Make an xmlns context something else that is a datatype

   <namespaces id="here" /> //cache all defined xmlns in this element's 

<namespaces refid="here" /> //extract the namespaces and add them to the 
parent node (i.e. the target)
<echo output="${resource}" />

Not sure whether I like that one.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message