Hi Neil,

thanks for your comments. I've inlined the replies below:

> The doc title "Unified Naming Scheme" seems rather grandiose and also
> hints at being more than the document describes - how about 
> "Standardised Namespaces for GGF"? 

Yes, you're right. I changed the document title accordingly.
 
> I'd reword the first section slightly: 
> The main purpose of GGF work is to produce documents. Many of these
> documents, if not the majority, are specifications to standardise Grid 
> Computing. Every Working Group and Research Group thus faces the 
> problem of structuring the namespace URI for their particular area of 
> interest. A non-exhaustive survey of current GGF research groups
> showed that the defined namespaces vary greatly. 
> Indeed, recurring patterns of identification within a larger organisational
> domain greatly improve communication and recognition both internal
> and external to an organisation. This very popular pattern has many
> names, of which the most commonly known is "Corporate Identity" in 
> the commercial world. 
> This document defines a small part of a greater "Grid Community 
> Identity" by standardising the way in which GGF Working Groups and, 
> possibly, Research Groups, organise their associated namespaces. 

Done as suggested.

> Section 2.4 should probably be Section 2.3.1. 

Yes, Donal also poinnted that out.

> In 2.5, you should reference the later section on extension. I'm also not
> sure it's entirely clear what you mean by "customs" but I haven't 
> thought of a better way to describe it yet. 

I've been looking for words other than customs but failed to get a better solution. I think "customs" describes as 
closest what is meant here: Indicating the general intended usage for this namespace. I intentionally wanted to avoid "
domain" or "sub-domain" as these terms are overloaded with DNS and URL meanings. Although one can interpret the 
generated namespaces as URLs (as long as they follow certain restrictions not outlined here, see Discussion related to 
Donals comments), the primary intention of this document is to defines unique *strings* without any semantics other that
 that.

 
> In 2.5.1, I'd reword the second sentence to say "All GGF specifications  ..." 

Done as suggested.

> In 2.6 I'd reword this to say "The domain part of the common-part 
> element of a namespace identifier associates the namespace with a 
> high-level community." I'd also put in something about the fact that 
> ggf.org (and gridforum.org?) should represent the Global Grid Forum 
> community. 

I split this section into two, defining "ggf.org" as a literal for GGF endorsed specifications.
This way, this section now aligns better with previous sections that define literal values, and the affiliation with GGF
 is more visible now.

> In the examples in 2.7, 2.8 etc, you should indicate when the example 
> is right, as well as when the example is wrong for clarity. 

Yes, you're right. I changed that already after receiving Donals comments.

> In 2.8, it is not clear to me why the acronyms must not contain hints on
> the nature of the group, also why they should not incorporate fractions 
> of other acronyms - surely this might cause problems? Is there a better
> way of defining a GGF Project name and acronym in a sensible, 
> non-overlapping fashion? 

This is actually a mix of several concerns. Surveying Gridforge and Sourceforge (whos software is used to run Gridforge)
, this general behaviour is a common practice. Also, the organisational structure of the standards body that defines 
namespaces should not creep into the namespace itself - whether the group is named "working group" or "research group" 
or "Grid Square Dance Caller Group" does not add any value to the namespace itself. Finally, this kind of information - 
if ultimatively needed - can be modeled using namespace "part" elements of arbitrary...