--- 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]