|
From: <gj...@al...> - 2007-04-18 19:28:19
|
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
|