Jose Alberto,
> -----Original Message-----
> From: Jose Alberto Fernandez [mailto:[EMAIL PROTECTED]
>
> Now, now, lets not go the same route on <rename> and push for only one way
> to do anything.
> Althugh I see your notation as necessary for completion. We still can keep
> the regular property notation as a form of shortcuts.
Sure, I agree. What I was trying to say was that I had started out by seeing
"property" as the string type and not a way of naming arbitrary datatypes.
So
<property name="blah" value="blah"/>
and
<fileset id="blah2">
would create two datatype instances "blah" and "blah2". These could be
accessed with refids or ${} syntax.
What Peter is saying is that property is a named datatype instance and we
therefore need to create the string type to take up the current property
usage. Either would seem OK to me. (We will need to standardize on "name" or
"id" for naming datatype instances)
>
> > A little verbose at first glance, compared with the current usage. In
> > any case, we are also going to need to decide the future of the ${}
> > syntax (too late to change it, IMHO) and what it would mean for
> > non-string properties (equivalent to toString() method, perhaps)
> >
>
> I see no major problem with ${} since the only reasonable definition,
> IMHO, is toString(). What I think is a larger problem is what to do about
> refid references. I think they would have to look in the "property name"
> space
> as well as the "id" space.
I think there should be just one namespace containing all named datatype
instances.
Someone mentioned the "id" space has
> to be local
> to the project by definition of the ID semantic in XML.
That was Stefan. I think we can change that since we have never published a
DTD :-) That is, I don't think we have ever officially designated the id
attribute as an ID.
> However, I think
> we still can interprete refids in whichever way we want since that is our
> own thing.
>
Agreed.
Conor
