- From: Bullard, Claude L (Len) <len.bullard@intergraph.com>
- Date: Tue, 15 Feb 2005 08:13:52 -0600
- To: "'martind@netfolder.com'" <martind@netfolder.com>, 'W3C TAG' <www-tag@w3.org>
Hi Didier: One way to look at it in context of the current thread is that the namespace doesn't identify the *collection*, it identifies the *collector* which might be a policy, a standard or a program. The problem is static names for dynamic collections. Either a separate flag is required (eg, a version att) or the name has to direct to the authority. As you point out, if the system is dynamic, that's better. No free lunch. BTW: I said 'one way' to look at it. As Patrick points out, the most conservative position is that it isn't an identifier or a locator, it is just syntax for walling off names and has no implications for sets or semantics. Even calling that a "name" is weak. Its 'meaning' is its value (UniqueWallZed). Of course, that reduces the utility of it considerably and it doesn't matter if a URI or a URN or a URL is there. In fact, it doesn't matter if it is a URanything, just a unique wall. len From: Didier PH Martin [mailto:martind@netfolder.com] Hi Len, Interesting, this is in the same vein as the actually sleeping trend in OO about reflectivity. If the system can be reflective enough to provide some meta information about itself its easier to adapt to it. For instance, we made some progresses in newer systems like Java or .NET when these latter provide some information about what is contained in an object. In other words, tell you more about its type definition. Every time a system becomes more reflective it also becomes more adaptable or it is more self documenting. Cheers Didier PH Martin
Received on Tuesday, 15 February 2005 14:14:24 UTC