Jeff W. Boote wrote:
Here I disagree 100%. That is like saying that FQDN's should not have any structure or implicit type information etc...
Ah! So what actually underlies this whole discussion is the issue of naming and addressing. Please, take the time to read: http://ana-3.lcs.mit.edu/~jnc/tech/ien/ien19.txt The important point there is:
The 'name' of a resource indicates *what* we seek,
an 'address' indicates *where* it is, and
a 'route' tells us *how to get there*.
But to come back to FQDNs, yes, they do have a very slight amount of implicit information. They contain exactly enough information so that, given a root server, you can resolve the *address* that is associated with that. Using the addres, you can then figure out a route to it, and actually get some useful information. Now, with FQDNs there is no choice, the lookup information has to be contained within that same term. I argue that in NML there is no need for this. The lookup part, or any other kind of implicit information, can be given using a separate property. The thing is, you are not going to see NML identifiers being handled out of context. Computer programs are going to need the context to make sense of it all. Jeroen.