Return-Path: 
 <ant-dev-return-31916-qmlist-jakarta-archive-ant-dev=jakarta.apache.org@jakarta.apache.org>
Delivered-To: apmail-jakarta-ant-dev-archive@apache.org
Received: (qmail 72562 invoked from network); 7 May 2002 16:03:11 -0000
Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131)
  by daedalus.apache.org with SMTP; 7 May 2002 16:03:11 -0000
Received: (qmail 19821 invoked by uid 97); 7 May 2002 16:03:11 -0000
Delivered-To: qmlist-jakarta-archive-ant-dev@jakarta.apache.org
Received: (qmail 19795 invoked by uid 97); 7 May 2002 16:03:10 -0000
Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:ant-dev-unsubscribe@jakarta.apache.org>
List-Subscribe: <mailto:ant-dev-subscribe@jakarta.apache.org>
List-Help: <mailto:ant-dev-help@jakarta.apache.org>
List-Post: <mailto:ant-dev@jakarta.apache.org>
List-Id: "Ant Developers List" <ant-dev.jakarta.apache.org>
Reply-To: "Ant Developers List" <ant-dev@jakarta.apache.org>
Delivered-To: mailing list ant-dev@jakarta.apache.org
Received: (qmail 19783 invoked by uid 98); 7 May 2002 16:03:10 -0000
X-Antivirus: nagoya (v4198 created Apr 24 2002)
X-Epoch: 1020787377
X-Sasl-enc: Qn+t8pgUSI2pFRk4MSHsTw
Message-ID: <012f01c1f5e0$aa850bd0$2ff1f682@har.mrc.ac.uk>
From: "Rob Oxspring" <roxspring@imapmail.org>
To: "Ant Developers List" <ant-dev@jakarta.apache.org>
References: 
 <5.1.0.14.0.20020506113601.03f50dd8@orson.callenish.com><5.1.0.14.0.20020506134604.03746d68@orson.callenish.com>
 <m3r8koyrqg.fsf@bodewig.bost.de>
Subject: Re: Selectors documentation and a Reference bug fix
Date: Tue, 7 May 2002 17:02:59 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

Firstly: please accept my apologies because I haven't helped code wise on
the selectors and on reading of this mail it looks like I'm wading in with
criticisms left, right and centre.  The work Bruce has done is great and
selectors will provide an extremely flexble mechanism with offering
intuitive clarity to first time users (IMHO).  I just want to try and get it
as close to right as possible before release so that we don't tie ourselves
to terms and defaults that may have better alternatives.

Static Selectors:
This term rubs a little as a Java developer since the classes have nothing
to do with the "static" keyword.  I realise this is meant to be as opposed
to dynamic selectors but maybe a term such as "Standard", "Core" or "Built
in" would be just as good without the meaning clash.  This is just a doc
thing that I'll happily submit a patch for when CVS has something to patch
against.

Date Selector:
Not wanting to start any pro/anti american battles but I hate the
"MM/DD/YYYY HH:MM AM_or_PM" on so many levels (its a pet of mine).  I think
the best option it probably to allow pattern= and locale= attributes ala
<tstamp/> and will happily send in a patch to do so (probably tomorrow
night) unless someone else beats me to it.  However I'd also suggest that
the default format changes - standards are there for a reason and although I
can't lay my hands on a copy of ISO8601, the format seems to be
"YYYY-MM-DDThh:mm:ss.sTZD" (http://www.w3.org/TR/NOTE-datetime).  I haven't
tried handling this exact varient in Java yet but at least
"YYYY-MM-DD[Thh:mm:ss]" could be handled with ease.  If nothing else the
year being first causes the average joe to at least consider which slots the
month and day should go in rather than make a mistaken assumption.

Extend Selector:
Like "static selectors" the term doesn't gell well for me. I think its
because "extend" is a verb which doesn't match with the others, alternatives
might be "extendedselector" or "customselector".  From the code it looks as
if this name is taken from the class name alone (need to get to know the
dynamic configuration better) so this might be best changed before any
commits are made.

When fields:
And now we reach the bottom of the pile.  When faced with <date
datetime="06/18/1979 00:00 AM"/> I would assume that it is going to select
files with exactly that date rather than anything before it.  I guess
"equal" is going to be the least used of the "when" possibilities but I
still feel its the logical default.  The argument makes sense to me with
<size size="1" units"Mi"/> too - seeing this for the first time I would
assume that we are talking exact matches rather than maximum. So how about
changing these defaults to equal when faced the less/equal/more question?

Okay, tirade over - comments & knock backs are welcome as ever!

Rob


----- Original Message -----
From: "Stefan Bodewig" <bodewig@apache.org>
To: <ant-dev@jakarta.apache.org>
Sent: Tuesday, May 07, 2002 3:09 PM
Subject: Re: Selectors documentation and a Reference bug fix


> On Mon, 06 May 2002, Bruce Atherton <bruce@callenish.com> wrote:
>
> >>   - For consistency, wouldn't <selectset> be better than <select>?
> >
> > I'm happy to call it whatever people want.
>
> I'm with Rob - <selector> may be better and <selectset> is misleading.
>
> > You are right, it would be cleaner to drop the "select" part
>
> +1
>
> > Is it too late for that kind of a change, though?
>
> The whole selector stuff hasn't been documented at all in 1.5beta1,
> has it?  I don't think we must stick to the names we have right now,
> but should stick to them as soon as we release documentation.
>
> Others?
>
> > It's fixed in my copy now.
>
> You may also want to make sure the example for <contains(select)>
> doesn't have a literal < in the contains attribute but a &lt; 8-).
>
> > Should I resubmit the whole tarball or just the one file?
>
> If we want to rename stuff, a new tarball may be the better option.
>
> Stefan
>
> --
> To unsubscribe, e-mail:   <mailto:ant-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>
>
>
>


--
To unsubscribe, e-mail:   <mailto:ant-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>