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:[EMAIL PROTECTED] 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: [EMAIL PROTECTED] > To: dev@ant.apache.org > Subject: Re: Adding magic properties for targets? > > On Mon, Jun 2, 2008 at 4:47 PM, Steve Loughran <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > _________________________________________________________________ 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
