ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Gainty <>
Subject RE: Adding magic properties for targets?
Date Mon, 02 Jun 2008 16:53:47 GMT

take a look at the spec for 'qualified name'

qualified name
is a name subject to namespace interpretation. 

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.

expanded name
corresponding to a prefixed element or attribute name has the

to which the
is bound as its
namespace name,
and the
local part
as its
local name.

2.2 Use of

as Namespace Names
The empty string, though it is a legal

reference, cannot be used as a namespace name.

The use of relative

including same-document references, in namespace declarations is
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
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:





      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

 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..

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:
> To:
> Subject: Re: Adding magic properties for targets?
> On Mon, Jun 2, 2008 at 4:47 PM, Steve Loughran <> 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:
> For additional commands, e-mail:

Make every e-mail and IM count. Join the i’m Initiative from Microsoft. MakeCount
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message