Re: ResourceCollections

[Matt Benson]

--- 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)
> 
> 
>   
> 
>   pattern="/MM/dd" />
>   
> 
> 
> A2:
> 
> 
>   
> 
>   pattern="/MM/dd"
> xmlns="ant:resourceselectors"/>
>   
> 
> 
Equivalent to above.  In each example the 
collection is also part of core.
> B1 (difference files allowed / mandated to be in rs
> namespace)
> 
> 
>   
> 
>   pattern="/MM/dd" />
>   
> 
> 
This says to me that files would be a duplicate
typedef in both core and ant:resourceselectors
namespaces.

> B2:
> 
> 
>   
>  xmlns="ant:resourceselectors"/>
>   pattern="/MM/dd"
> xmlns="ant:resourceselectors"/>
>   
> 

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.
> 
> 
>   
> 
>   pattern="/MM/dd" />
>   
> 
> 
> C2:
> 
> 
>   
> 
>   pattern="/MM/dd" />
>   
> 
> 

The two above are similar, again.  I see why you would
want C2, but I am fairly unwilling to have 
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 .  But if the files can't live in
the rs namespace, I'm guessing you'd have:

C3:


  


  


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  will be in
core, the only difference becomes the namespace on the
 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.

> 
>   
> 
>   pattern="/MM/dd" />
>   
> 
> 
> 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]

DO NOT REPLY [Bug 34461] - problems with core task

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=34461


[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

Re: ResourceCollections

[Martijn Kruithof]

Matt Benson wrote:
--- Martijn Kruithof <[EMAIL PROTECTED]> wrote:
[SNIP]
 

Apart from the variands A and B further below, would
the following also 
work?



  
  
  
  


or would this mean that the resoursecollection must
be part of set itself?
   

As I understand it, yes, because the xmlns was
declared on the resourcecollection element.  I am
having a hard time following your exact example here
because I'm not sure how you are imagining the
ResourceCollections to look, while I know what they
look like.  :)
 

I'll use your example below to ask what will be (im)possible
I don't see that the ResourceCollections themselves
need a namespace. 

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.

I have modified FileSet and similar
existing types to implement ResourceCollection. 
Really the whole problem goes back to and/or/not, etc.
"The Princess and the Pea."  Anyway, I translate your
example above as:


 
   
   
   
   
 

 

Why would the date have the rs namespace and the files not, both are 
used inside the resourcecollection?

Does that make sense?
-Matt
 

So now up to the alternatives using the names of above example (Same 
letter means equivalent in XML):
A1 (shameless copy from above)


 
   
   
 


A2:

 
   
   
 

B1 (difference files allowed / mandated to be in rs namespace)

 
   
   
 


B2:

 
   
   
 

C1  (difference now allos restric allowed / mandated to be in rs 
namespace, maybe a better name would in that case be resourcecollections)


 
   
   
 


C2:

 
   
   
 


D: (no namespace at all, with the danger and problems of clashes, 
extensively discuussed before.)


 
   
   
 


Are there any other variations possible, are variant A-D feasible, and 
what is best. (I'd currently say B or C)

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