Where exactly 2 values are specified, they are interpreted as x, y with no spatial extent (a point).
Where exactly 3 values are specified, they are interpreted as x, y, R.
Where exactly 4 values are specified, they are interpreted as x, y, z, R.
x, y, z are X, Y (and Z) coordinates in the current scheme. R is
a radius value in the same scheme.
Where z values are not specified, the x,y pairs form
an ordered set defining the edge of a polygon in an anticlockwise direction.
Where z values are specified, the region is defined as
the minimum convex hull enclosing all x,yz triples.
Coverage.Spatial.Region and Coverage.Spatial.Void elements may be repeated. The coverage defined for the object is the sum of all Region elements minus the Void elements
If no scheme is specified:
The following abbreviations may be used:
In decimal and fractional notation, approximate precision of the data shall be indicated by the number of decimal places. In computation, some effort shall be made that this information is not lost.
If a UTM scheme is used, the zone number and hemisphere (N,S) shall be indicated in the scheme. Positions shall be defined as (Eastings, Northings, Elevation) in metres.
Where 3-dimensional regions are defined, an algorithm such as Bowyer-Watson may be used to generate the Delaunay Tessellation, and derive the convex hull of the given point set. Concave hulls which cannot be defined using an unordered point set may instead be defined using a void to produce the concave region.

A two-dimensional analog of the convex hull derivation from an unordered
set of points. Here, the smallest convex polygon enclosing the points is
constructed. In threee dimensions, the snmallest convex polyhedron
is constructed.
A 50 metre circle around my office:
content="-123.382 49.410 50">
A more precise measurement:
content="-123.38194 49.40973 50.0">
content="483233 5454797">
A 50 foot circle around my office:
content="49°14'44"N 123°13'49"W 50ft">
A 100 metre sphere around my office:
content="483233 5454797 65 100">
My office building plan:
content="
483200 5454800, 483220 5454800, 483220 5454830,
483200 5454830, 483200 5454820, 483210 5454820, 483210 5454810,
483200 5454810
">
My office building:
content="
483200 5454800 70, 483220 5454800 70, 483220 5454830 70,
483200 5454830 70,
483200 5454800 74, 483220 5454800 74, 483220 5454830 74,
483200 5454830 74
">
content="
483200 5454810 70, 483210 5454810 70,
483220 5454820 70, 483200 5454820 70,
483200 5454810 74, 483210 5454810 74,
483220 5454820 74, 483200 5454820 74
">
(defined using a void; the set of points is
actually the Coordinate3 element from the VRML file)
content="
483200 5454800 70, 483220 5454800 70,
483220 5454810 70, 483200 5454810 70,
483200 5454800 74, 483220 5454800 74,
483220 5454810 74, 483200 5454810 74
">
content="
483220 5454810 70, 483220 5454820 70,
483210 5454820 70, 483210 5454810 70,
483220 5454810 74, 483220 5454820 74,
483210 5454820 74, 483210 5454810 74
">
content="
483220 5454820 70, 483220 5454830 70,
483200 5454830 70, 483200 5454820 70,
483220 5454820 74, 483220 5454830 74,
483200 5454830 74, 483200 5454820 74
">
(defined using 3 convex regions)

A polygonal area.

A rectangle with a triangular and a circular void.

A square with a circular bite from one corner.
In the case of complex shapes, specifying the format unambiguously is costly in terms of space, and therefore confusing to humans, because it becomes too large to comprehend at a glance. Therefore it is desirable to have the ordering and value of unqualified coordinates defined.
Ordering a set of coordinates which define a boundary is fairly intuitive for most people and therefore it is feasible to use an ordered set of points which permits concave shapes.
Defining a solid volume is less intuitive and requires the provision of not only vertex coordinates but also face sets. Using the convex hull approach permits a simpler definition of coordinates, while allowing many shapes such as cubes, pyramids (at arbitrary orientation) to be sepcified in one element. More complex elements may be built by using several convex regions or voids.
I believe that the conventions proposed above may be parsed unambiguously by an agent, providing that no typographical errors are made such as dropping commas.
It might be nice to be able to select from a restricted set, e.g.
Suggestions:
How about ?
though I'll go along with x, y, z in the interests of getting something accomplished.
This is the kind of thing that someone might read from a GPS set, or a topo map. There is sufficient
information to distinguish seconds from minutes, latitude from longitude, metres from feet.
I think that if Web agents can deal with about four different date formats, that they should
be able to deal with different, unambiguous, spatial formats.
Where precision is required, or the body in question is not the Earth, use a schema
The instructions for using the schema may specify the format to be used. Note that lay users entering data ought to be able to discover the datum used (at least for recent material), but may not have access to translation software (such as PROJ.4).