You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Steve Loughran <st...@apache.org> on 2008/06/02 13:12:04 UTC
Re: Adding magic properties for targets?
Dominique Devienne wrote:
> I'd add that those properties, if made available, should probably be
> prefixed with ant., to make it clear they are "built-in". Perhaps:
>
> ant.default-target
> ant.targets-invoked
>
> I'm +0 on adding these "static" properties.
>
> Since we're at it, we may also want to expose ant.current-target and
> ant.invoked-target properties, but these are "dynamic" since changing
> during the course of the build, so more problematic given the property
> immutability rules. Exposing them via a PropertyHelper to made it
> clear they are dynamic perhaps? ${dynamic:ant.current-target}...
That could be very good. I'm happier with that than using something that
looks like an existing property and could easily stamp on existing
properties
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
RE: Adding magic properties for targets?
Posted by Martin Gainty <mg...@hotmail.com>.
take a look at the spec for 'qualified name'
http://www.w3.org/TR/REC-xml-names/#dt-NSName
qualified name
is a name subject to namespace interpretation.
[Definition:
An XML namespace is identified by
a URI reference [RFC3986];
element and attribute names
may be placed in an XML namespace using the mechanisms described
in this specification.
]
The
expanded name
corresponding to a prefixed element or attribute name has the
URI
to which the
prefix
is bound as its
namespace name,
and the
local part
as its
local name.
2.2 Use of
URIs
as Namespace Names
The empty string, though it is a legal
URI
reference, cannot be used as a namespace name.
The use of relative
URI
references,
including same-document references, in namespace declarations is
deprecated.
Note:
This deprecation of relative URI references was decided on by a
W3C XML Plenary Ballot [Relative URI deprecation]. It also declares that
"later specifications such as DOM, XPath, etc. will define no
interpretation for them".
so a URI declared in
http://www.rfc-editor.org/rfc/rfc3986.txt
defines URI as
A Uniform Resource Identifier (URI) is a compact sequence of
characters that identifies an abstract or physical resource. This
specification defines the generic URI syntax and a process for
resolving URI references that might be in relative form, along with
guidelines and security considerations for the use of URIs on the
Internet. The URI syntax defines a grammar that is a superset of all
valid URIs, allowing an implementation to parse the common components
of a URI reference without knowing the scheme-specific requirements
of every possible identifier. This specification does not define a
generative grammar for URIs; that task is performed by the individual
specifications of each URI scheme.
here are (thankfully concrete) examples
1.1.2. Examples
The following example URIs illustrate several URI schemes and
variations in their common syntax components:
ftp://ftp.is.co.za/rfc/rfc1808.txt
http://www.ietf.org/rfc/rfc2396.txt
ldap://[2001:db8::7]/c=GB?objectClass?one
mailto:John.Doe@example.com
news:comp.infosystems.www.servers.unix
tel:+1-816-555-1212
telnet://192.0.2.16:80/
urn:oasis:names:specification:docbook:dtd:xml:4.1.2this is the part that gets ambiguous:
A URI can be further classified as a locator, a name, or both. The
term "Uniform Resource Locator" (URL) refers to the subset of URIs
that, in addition to identifying a resource, provide a means of
locating the resource by describing its primary access mechanism
(e.g., its network "location"). The term "Uniform Resource Name"
(URN) has been used historically to refer to both URIs under the
"urn" scheme [RFC2141], which are required to remain globally unique
and persistent even when the resource ceases to exist or becomes
unavailable, and to any other URI with the properties of a name.
An individual scheme does not have to be classified as being just one
of "name" or "locator". Instances of URIs from any given scheme may
have the characteristics of names or locators or both, often
depending on the persistence and care in the assignment of
identifiers by the naming authority, rather than on any quality of
the scheme. Future specifications and related documentation should
use the general term "URI" rather than the more restrictive terms
"URL" and "URN" [RFC3305].
Now lets take a look at RFC2141 on how to properly construct a URN
http://www.rfc-editor.org/rfc/rfc2141.txt
All URNs have the following syntax (phrases enclosed in quotes are
REQUIRED): <URN> ::= "urn:" <NID> ":" <NSS>CONCLUSION:
a URN is required to remain globally unique and persistent even when the resource ceases to exist or becomes unavailable, and to any other URI with the properties of a name
So it would seem once can easily infer a globally unique requirement
But one cannot infer that the resource must exist or be available
I think there is enough ambiguity with the last statement that a reconsideration for RFC3305
may be in order..
Thoughts?
Martin Gainty
______________________________________________
Disclaimer and confidentiality note
Everything in this e-mail and any attachments relates to the official business of Sender. This transmission is of a confidential nature and Sender does not endorse distribution to any party other than intended recipient. Sender does not necessarily endorse content contained within this transmission.
> Date: Mon, 2 Jun 2008 17:33:45 +0200
> From: james.fuller.2007@gmail.com
> To: dev@ant.apache.org
> Subject: Re: Adding magic properties for targets?
>
> On Mon, Jun 2, 2008 at 4:47 PM, Steve Loughran <st...@apache.org> wrote:
> > No, QNames are (a) evil (b) not part of XML; they ar part of the W3C XML
> > Schema.
>
> hehe, this was exactly the response I predicted.
>
> ok, I will play along .....
>
> > I've just noticed the that Open Grid Forum's Open Grid Services
> > Architecture mailing list has just discovered that very fact only weeks
> > before their WS-ResourceFramework Basic Profile 1.0 was about to be
> > announced (I'm on some very obscure mailing lists)...I think I pointed that
> > out to them years back.
>
> the suggested;
>
> ant.some-default-setting
>
> works for me, but inevitably there will be someone who will want to
> use ant. and overload the prefix, etc... so u could either make
> something up or reuse something in existence.
>
> so I think the decision is one of scope; fine for Ant to choose to do
> something tactical, though strategically it may make more sense to
> build in XML namespaces and qnames.
>
> > Here's the basic problem, and it exists in XPath too: you cannot evaluate
> > the prefix to namespace URI mapping without building and maintaining the
> > entire context of namespace declarations. And you get a new error type
> > -unknown prefix- that is not needed. That is, it would be better to pass
> > around things like
>
> I have been reading this permathread for nearly a decade, I probably
> have argued on both sides of it ... with you, got the t-shirt ;)
>
> > See? QNames are evil.
>
> I would state that it is hard to completely bound any construction in
> any computing language ... there are plenty of technologies with a
> frightening degree of ambiguity that thrive and I think when the
> principle of 'least surprise', 'least evil' and common sense is
> applied then these ambiguities can be navigated around... there are
> plenty of other XML technologies that use qname and XML namespaces
> that are fine and I am sure that Ant would be fine as well.
>
> > I had lunch with the W3C TAG last week, primarily to give them a hard time
> > over releasing WS-Addressing without a single test case(*). I guess I should
> > have raised QNames at the same time.
>
> test cases are good ... if u mean not a single test case with qnames
> ... I am admittedly lost, I must confess to ignoring most of what XML
> Schema or any WS-anything espouses.
>
> back to the point; perhaps I am unaware of the costs of implementing
> qnames in current Ant ... it might be quite high and you being
> intimately aware of these costs might be conflating the argument and
> deciding the benefits are not worth the effort.
>
> as a thought experiment, I wonder what benefits there would be
> (keeping in mind that we would avoid the nuclear scenario you outline
> with qnames) to implementing qnames in property names (perhaps all
> names) in Ant?
>
> now that I am in a wondering mood ... what is the verdict with Ant
> libraries and its usage of XML namespaces ... was this considered a
> good thing ?
>
> cheers, Jim Fuller
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
_________________________________________________________________
Make every e-mail and IM count. Join the i’m Initiative from Microsoft.
http://im.live.com/Messenger/IM/Join/Default.aspx?source=EML_WL_ MakeCount
Re: Adding magic properties for targets?
Posted by James Fuller <ja...@gmail.com>.
On Mon, Jun 2, 2008 at 4:47 PM, Steve Loughran <st...@apache.org> wrote:
> No, QNames are (a) evil (b) not part of XML; they ar part of the W3C XML
> Schema.
hehe, this was exactly the response I predicted.
ok, I will play along .....
> I've just noticed the that Open Grid Forum's Open Grid Services
> Architecture mailing list has just discovered that very fact only weeks
> before their WS-ResourceFramework Basic Profile 1.0 was about to be
> announced (I'm on some very obscure mailing lists)...I think I pointed that
> out to them years back.
the suggested;
ant.some-default-setting
works for me, but inevitably there will be someone who will want to
use ant. and overload the prefix, etc... so u could either make
something up or reuse something in existence.
so I think the decision is one of scope; fine for Ant to choose to do
something tactical, though strategically it may make more sense to
build in XML namespaces and qnames.
> Here's the basic problem, and it exists in XPath too: you cannot evaluate
> the prefix to namespace URI mapping without building and maintaining the
> entire context of namespace declarations. And you get a new error type
> -unknown prefix- that is not needed. That is, it would be better to pass
> around things like
I have been reading this permathread for nearly a decade, I probably
have argued on both sides of it ... with you, got the t-shirt ;)
> See? QNames are evil.
I would state that it is hard to completely bound any construction in
any computing language ... there are plenty of technologies with a
frightening degree of ambiguity that thrive and I think when the
principle of 'least surprise', 'least evil' and common sense is
applied then these ambiguities can be navigated around... there are
plenty of other XML technologies that use qname and XML namespaces
that are fine and I am sure that Ant would be fine as well.
> I had lunch with the W3C TAG last week, primarily to give them a hard time
> over releasing WS-Addressing without a single test case(*). I guess I should
> have raised QNames at the same time.
test cases are good ... if u mean not a single test case with qnames
... I am admittedly lost, I must confess to ignoring most of what XML
Schema or any WS-anything espouses.
back to the point; perhaps I am unaware of the costs of implementing
qnames in current Ant ... it might be quite high and you being
intimately aware of these costs might be conflating the argument and
deciding the benefits are not worth the effort.
as a thought experiment, I wonder what benefits there would be
(keeping in mind that we would avoid the nuclear scenario you outline
with qnames) to implementing qnames in property names (perhaps all
names) in Ant?
now that I am in a wondering mood ... what is the verdict with Ant
libraries and its usage of XML namespaces ... was this considered a
good thing ?
cheers, Jim Fuller
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Adding magic properties for targets?
Posted by Steve Loughran <st...@apache.org>.
James Fuller wrote:
> wouldn't it be great if property names were qnames and then we could do
>
> ant:default-target
> ant:targets-invoked
>
> though I do not think the default namespace e.g.
> antlib:org.apache.tools.ant is wholly appropriate as it concerns
> itself with ant libraries.
>
> I know ant doesn't fully subscribe to all things xml ... but there
> maybe benefits to not reinventing things.
No, QNames are (a) evil (b) not part of XML; they ar part of the W3C XML
Schema.
I've just noticed the that Open Grid Forum's Open Grid Services
Architecture mailing list has just discovered that very fact only weeks
before their WS-ResourceFramework Basic Profile 1.0 was about to be
announced (I'm on some very obscure mailing lists)...I think I pointed
that out to them years back.
Here's the basic problem, and it exists in XPath too: you cannot
evaluate the prefix to namespace URI mapping without building and
maintaining the entire context of namespace declarations. And you get a
new error type -unknown prefix- that is not needed. That is, it would be
better to pass around things like
<qname>http://example.org#ename<qname>
Or even
<qname><uri>http://example.org</uri><localname>ename<localname><qname>
than it would be to have
<qname>example:ename</qname>
because you can only evaluate element within the context of the original
scope.
Now imagine the <qname> task takes a property and sets it to the
expanded http://example.org#ename string, and use it in a presetdef
<target xmlns:example="http://ant.apache.org"/>
<presetdef name="eval">
<qname>example:ename</qname>
</presetdef>
</target>
and then I run it here
<target xmlns:example="http://somethingelse" >
<eval property="evaluated" />
</target>
What gets expanded?
Or we run it here, where the namespace is entirely undefined:
<target >
<eval property="evaluated" />
</target>
See? QNames are evil.
I had lunch with the W3C TAG last week, primarily to give them a hard
time over releasing WS-Addressing without a single test case(*). I guess
I should have raised QNames at the same time.
-Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Adding magic properties for targets?
Posted by James Fuller <ja...@gmail.com>.
On Mon, Jun 2, 2008 at 1:12 PM, Steve Loughran <st...@apache.org> wrote:
> Dominique Devienne wrote:
>>
>> I'd add that those properties, if made available, should probably be
>> prefixed with ant., to make it clear they are "built-in". Perhaps:
>>
>> ant.default-target
>> ant.targets-invoked
>>
>> I'm +0 on adding these "static" properties.
>>
>> Since we're at it, we may also want to expose ant.current-target and
>> ant.invoked-target properties, but these are "dynamic" since changing
>> during the course of the build, so more problematic given the property
>> immutability rules. Exposing them via a PropertyHelper to made it
>> clear they are dynamic perhaps? ${dynamic:ant.current-target}...
>
> That could be very good. I'm happier with that than using something that
> looks like an existing property and could easily stamp on existing
> properties
wouldn't it be great if property names were qnames and then we could do
ant:default-target
ant:targets-invoked
though I do not think the default namespace e.g.
antlib:org.apache.tools.ant is wholly appropriate as it concerns
itself with ant libraries.
I know ant doesn't fully subscribe to all things xml ... but there
maybe benefits to not reinventing things.
my 2czk,
cheers, Jim Fuller
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org