--- Martijn Kruithof <[EMAIL PROTECTED]> wrote:
> I'll use your example below to ask what will be
> (im)possible
>
> The question is not whether the resourcecollection
> themselve need a
> namespace, but if it would be allowed to address
> elements from the same
> namespace, so that the default namespace declaration
> would work for the
> entire nested set of elements, including the
> element itself.
>
> Why would the date have the rs namespace and the
> files not, both are
> used inside the resourcecollection?
Because the files are (will be) a core type, like
fileset. The selectors are where the name collisions
are, so they are what should be "packaged."
>
> So now up to the alternatives using the names of
> above example (Same
> letter means equivalent in XML):
> A1 (shameless copy from above)
>
> <project xmlns:rs="ant:resourceselectors">
> <restrict>
> <files name="${basedir}/foo/**/*.java" />
> <rs:date when="after" datetime="2005/04/15"
> pattern="yyyy/MM/dd" />
> </restrict>
> </project>
>
> A2:
>
> <project>
> <restrict>
> <files name="${basedir}/foo/**/*.java" />
> <date when="after" datetime="2005/04/15"
> pattern="yyyy/MM/dd"
> xmlns="ant:resourceselectors"/>
> </restrict>
> </project>
>
Equivalent to above. In each example the <restrict>
collection is also part of core.
> B1 (difference files allowed / mandated to be in rs
> namespace)
>
> <project xmlns:rs="ant:resourceselectors">
> <restrict>
> <rs:files name="${basedir}/foo/**/*.java" />
> <rs:date when="after" datetime="2005/04/15"
> pattern="yyyy/MM/dd" />
> </restrict>
> </project>
>
This says to me that files would be a duplicate
typedef in both core and ant:resourceselectors
namespaces.
> B2:
>
> <project>
> <restrict>
> <files name="${basedir}/foo/**/*.java"
> xmlns="ant:resourceselectors"/>
> <date when="after" datetime="2005/04/15"
> pattern="yyyy/MM/dd"
> xmlns="ant:resourceselectors"/>
> </restrict>
> </project>
Equivalent to above.
>
> C1 (difference now allos restric allowed / mandated
> to be in rs
> namespace, maybe a better name would in that case be
> resourcecollections)
I see where this is going. First, I don't know that
there is a reason to scope all (new)
ResourceCollections out of core, as long as their
names don't conflict with existing components.
>
> <project xmlns:rs="ant:resourceselectors">
> <rs:restrict>
> <rs:files name="${basedir}/foo/**/*.java" />
> <rs:date when="after" datetime="2005/04/15"
> pattern="yyyy/MM/dd" />
> </rs:restrict>
> </project>
>
> C2:
>
> <project>
> <restrict xmlns="ant:resourceselectors">
> <files name="${basedir}/foo/**/*.java" />
> <date when="after" datetime="2005/04/15"
> pattern="yyyy/MM/dd" />
> </restrict>
> </project>
>
The two above are similar, again. I see why you would
want C2, but I am fairly unwilling to have <files>
live in other than core, so I'm not sure how you could
achieve it (comfortably). C2 syntax is why you would
want restrict to live with the selectors. That is at
least sensible, since as I said, there should be
little (no) use for resourceselectors outside the
context of <restrict>. But if the files can't live in
the rs namespace, I'm guessing you'd have:
C3:
<project>
<restrict xmlns="ant:resourceselectors">
<files name="${basedir}/foo/**/*.java" xmlns="" />
<date when="after" datetime="2005/04/15"
pattern="yyyy/MM/dd" />
</restrict>
</project>
But I don't know if that's any better, as you then
have to resolve the core type instead of the
selectors. As for C1, assuming <files> will be in
core, the only difference becomes the namespace on the
<restrict> element, which is just a little more
typing, then.
> D: (no namespace at all, with the danger and
> problems of clashes,
> extensively discuussed before.)
>
AFAIK this would, at this point, take some good
guessing code in the core (!) or DynamicElement
processing.
> <project>
> <restrict>
> <files name="${basedir}/foo/**/*.java" />
> <date when="after" datetime="2005/04/15"
> pattern="yyyy/MM/dd" />
> </restrict>
> </project>
>
> Are there any other variations possible, are variant
> A-D feasible, and
> what is best. (I'd currently say B or C)
>
I never claim to know what's best (or at least I don't
think I do).
-Matt
> Martijn
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
>
>
__________________________________
Yahoo! Mail Mobile
Take Yahoo! Mail with you! Check email on your mobile phone.
http://mobile.yahoo.com/learn/mail
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
