--- Steve Loughran <[EMAIL PROTECTED]> wrote:

> Stefan Bodewig wrote:
> > On Wed, 21 Mar 2007, Matt Benson
> <[EMAIL PROTECTED]> wrote:
> > 
> >> I think what is needed is a well-known syntax
> specification for
> >> specifying a string representation of
> [resource-type][String to pass
> >> to constructor] e.g. "file?/foo/bar.baz",
> >> "url?http://www.apache.org";, "string?blah blah
> blah".
> > 
> > This is so I can say
> > 
> > <unzip
> >  
>
src="url?http://www.apache.org/dist/ant/.../ant-bin-current.zip"/>
> > 
> > instead of
> > 
> > <unzip>
> >   <url
>
url="http://www.apache.org/dist/ant/.../ant-bin-current.zip"/>
> > </unzip>
> > 
> > right?
> > 
> > Sounds right.
> 
> 
> > 
> >> This is to all intents and purposes the only way,
> IMHO, to seriously
> >> take advantage in Ant tasks of our early decision
> to design
> >> getOutputStream() into the Resource contract. 
> You'll notice my use
> >> of the "?" character above to indicate the
> preceding text was the
> >> name of a currently available type.  I used "?"
> because for xmlns as
> >> well as fs reasons I'm pretty sure this character
> should NOT be a
> >> colon.
> > 
> > I agree that a colon would be a bad choice, at
> least if we allow file
> > ressources to be specified without a prefix.  I
> don't really see any
> > conflict with xmlns.
> 
> ah, this is starting to scare me.

Then my work is done!  ;)

> 
>   you'd need qname resolution in string to support
> custom resources
> 
> <unzip
>    
>
src="tns:url?http://www.apache.org/dist/ant/.../ant-bin-current.zip"/>
> 
>   I hate those because they only resolve relative to
> where they are defined
> 
> <property name="url" 
>
value="tns:url?http://www.apache.org/dist/ant/.../ant-bin-current.zip";
>   xmlns:tns="http://example.org"; />
> 
> this defines the url property with the tns namespace
> in scope
> 
> but where it is used, it may be absent
> 
> <unzip
>     src="${url}">
> 
> or defined to something else
> 
> <unzip
>     src="${url}" xmlns:tns="http://something-else"/>
> 
> So you're going to have to retaiin the entire list
> of in-scope XMLNS 
> declarations in every property you define. Now, what
> if its a custom 
> task that creates the string?  is
> Project.setNewProperty() going to have 
> to take a reference to the node in the DOM graph
> where the current task 
> is working?
> 
> 
> You may think I'm being a troublemaker here, but I

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

> 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 antlib:org.foo/type

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?

br,
Matt

> > 
> >> However I'm not sure what the RIGHT "trigger
> character" is and IMO
> >> this is the only outstanding question stopping us
> from adding this
> >> feature to Ant.
> 
> that and how to correctly handle xml namespaces.
> 
> -steve
> 
> 
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
> 
> 



 
____________________________________________________________________________________
Get your own web address.  
Have a HUGE year through Yahoo! Small Business.
http://smallbusiness.yahoo.com/domains/?p=BESTDEAL

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to