[Spatialml-discussion] some comments

[<gj...@al...>]

Generally, this looks good to me.  Comments below:

Content-related comments:

1. A gazetteer reference is made using the gazref attribute, which  
takes the form prefix:identifier.  Have you considered making such  
references href-style URLs?  For then a client could automatically  
follow a gazref link and retrieve the associated place information.   
I realize that gazetteer record formats are not yet standardized, nor  
is the identification of places by URIs, but this is a use case that  
could help drive such standardization.  As SpatialML stands now, a  
client needs three document-external pieces of information to follow  
a gazref: the location of the gazetteer being referred to; the  
protocol for accessing that gazetteer; and the format of that  
gazetteer's records.  (Also, see comment #6 below).

2. PLACEs identify (by surrounding with XML tags) relevant portions  
of the document.  PATHs do, too, via SIGNALs.  But LINKs don't.   
Perhaps, by symmetry, they should?  For example, a LINK could  
surround the relevant preposition ("in") or punctuation (",").

3. Seems like the document should at least suggest a format for  
latitude/longitude coordinates.

4. Why is PLACE's id attribute required when no other attribute is?

XML comments:

5. XML elements should be defined in a namespace, so that they can be  
embedded in namespace-aware documents.

6. If gazetteers are identified by prefixes, consider using the XML  
namespace mechanism to correlate prefixes with gazetteer URLs.  This  
technique is used in XML Schema, for example.

Exposition comments:

7. Consider rephrasing sentences having "we" in them (e.g., "we try  
to keep the extents as small as possible...") to passive requirements  
("guideline: extents should be kept as small as possible...").  As it  
is, the spec reads a little like a project-specific document instead  
of a community standard.  This is also an opportunity to revisit some  
of those statements: are they really requirements?  Or guidelines?   
Best practices that everybody should follow?  MITRE- or project- 
specific?  Etc.

8. I don't understand the distinction between cities, towns, and  
villages in CTV.  Should I?

Minor points:

9. Some codes are abbreviated (RGN), some are spelled out  
(BODYOFWATER).  I take it some were copied, but I guess I would  
strive for consistency here.

10. More generally, the use of abbreviations counters XML's goal and  
virtue of self-documentation.  Coded abbreviations like mod="BR" are  
already inscrutable to me, and I read the spec all of 5 minutes ago.   
Why not spell it out, i.e., modifier="BORDER"?

-Greg