Considering the DataModel, correct me if i am wrong, but what is
important are the coordinates themselves (which ones, in which reference
frame, what accuracies on them, etc), not their format. Physically,
this things are angles, and already, In the international system MKSA,
angles are expressed in RADIANS... Is this sexagesimal question really
part of DM work?
Anyway, enforcing a better use of the sexagesimal notation for coordinates and _times_ is a good idea, although I do not think today's data producer amuse themselves to write "borderline" sexagesimal coordinates/times.
In fact, since the whole planet use sexagesimal notation for time, it has been de facto fixed by ISO 8601 standard, and it would only complicate things if VO standards were markedly different from ISO ones.
For me, a sexagesimal notation of a real number is 3 numerical fields
separated by ONE "separator type". The purpose of this notation
is to encode in a traditional historical complicated way a real number,
which is obtained by the formula:
value = PI / 180 * first_field*3600.0+second_field*60.0+third_field.
Note that if, according to Murphy rule, the "value" you obtained is of
type "right ascension" or "time", then you have to multiply by 15.0
"value" to get radians and start doing physics.
Rule: the first field is a signed integer (but sign may be omitted if positive), the second an unsigned integer of TWO digits not greater than 59, the third an unsigned float of any precision, absolutely less than 60.0, whose integer part is written with TWO digits. If, when writing the sexagesimal value, the rightmost field is null, it, and its separator from the fields to its left, can be omitted (and the process repeated until exhaustion of simplification). The separator between the fields is THE SAME (like ins CSV) , but can be an abstract construction:
are all OK, since for the last example the separator is of the <sup> persuasion (to quote Piers Anthony). You could even have a bit of java code making a separator in a widget, between <java> tags!
Note that the "null" separator is allowed because 6435 is 64:35 and not 643:5 since the last fields have two digits or none. Note also this is of the same line of thought as in the ISO recommandation for DATE (the separator is "-": 1955-02-04)
This leaves out perfectly human-readable values (using 100% of their brain capacity):
... But recommending the form "(+)64:35:26.546" would be a good idea. And recommending that angles be expressed as floats, not sexagesimal, and perhaps even in radians (after all, nobody's going to look at the XML, all values will be mediated by data converters in the user's preferences), would be a still better idea.
Best
Gilles