Hi Stephen, On Friday 27 March 2009 10:25:19 Burke, S (Stephen) wrote:

I think I'd be inclined to leave this as free-format text, I don't see a strong case where you'd need to parse it automatically

How about "finding out which CE job managers are in use at UK sites". See [1] [1] http://egee-uig.web.cern.ch/egee-uig/production_pages/Advancedldapsearch.htm...

and this sort of thing can be politically sensitive.

True, but we defer that discussion (and corresponding political sensitivity) to ISO. Also, ISO 3166-1 includes user-assigned codes that may be used to describe countries not recognised by ISO. In any case, we do not mandate that people use ISO 3166-1; although other codes should not (RFC-2119) be used, it isn't forbidden.

Also remember that locations can be broad, for example the nordugrid distributed tier-1 may want a list there.

Certainly, anyone can place any text they wish there. I am not suggesting we mandate ISO 3166-1; rather that we say which code should be used. I think the example you present isn't a strong argument. The location has multiplicity "optional" (0..1), so using this field to represent a list doesn't seem appropriate. To me, a more natural representation would be to leave the Location.country field blank and to publish four AdminDomains (one for each member country). Each of these would be a sub-Domain of the Nordugrid AdminDomain and would publish a Location object with Location.country specified using the appropriate ISO 3166-1 code. Of course, Nordugrid are free to publish their Tier-1's Location.country attribute as a comma-separated list of member countries. However, I feel that if many people do this we should review the multiplicity of this field. On Friday 27 March 2009 10:26:46 Burke, S (Stephen) wrote:

... and of course the UK is not a country - England, Scotland and Wales are countries!

In fact, UK *is* a country, as are England, Scotland and Wales. See: http://en.wikipedia.org/wiki/United_Kingdom The thing that confuses people is that Great Britian isn't a country, but an island. Further confusing is that the UK ISO 3166-1 code is "GB" (2-letter) or "GBR" (3-letter). There isn't an ISO 3166-1 code for England, Scotland or Wales, so one can only represent an AdminDomain in England as UK, with corresponding code "GBR". It's this sort of confusion I'd advocate we should avoid by recommending ISO 3166-1 Alpha-3 for Location.country. Cheers, Paul.

Hi Stephen, On Friday 27 March 2009 12:30:15 Burke, S (Stephen) wrote:

Paul Millar [mailto:paul.millar@desy.de] said:

...

How about "finding out which CE job managers are in use at UK sites".

I think that would be an abuse of the attribute; people should use the AdminDomain structure for that kind of thing.

But the Location object is tied to the AdminDomain (amongst other classes), so I don't see this as an abuse: the Location objects describe where things are. If one wishes to group objects by country then (to me) it seems natural that Location objects be used and Location.country attribute be processed. Moreover, I don't see how else one can answer the question without making potentially fragile assumptions. For example, one cannot assume that a country forms a single AdminDomain, or that the some other attribute (with a DNS component) ends with the country-specific TLD. So, I'm curious how one answers the above question with GLUE 2.0 without processing the published Location.country attributes.

Anyway I don't think we should change the schema any more, we've discussed this for two years and anything non-critical should wait for glue 2.1 ...

The issue is when will GLUE 2.1 come out? If we go for a time-based release process (say every six months, if a new release is meritted) then I'm perfectly happy to delay this for GLUE v2.1. Cheers, Paul.