Peter,
> from quick read of this the one thing that stood out as missing was a
> concept of formal applicability. Clearly mappings defined this way have a
> very limited scope, so some way of accessing their appropriateness is
> needed, i.e. you need metadata to define what the input and output systems
> can be.
Not sure I understand your comment. By "metadata to define what the input
and output systems can be", do you mean the equivalent of a pair of AST
Frames to say what the input and output coordinates are?
> I presume that the passing reference to "plus property accessor methods",
> hides the fact that these mappings are also configurable to match specific
> instances of input and output systems.
I just meant it in the sense of AST property accessors like "astGetZoom"
to get the Zoom property of a ZoomMap, etc, or "astGetNin" to get the
number of input coordinates or a Mapping.
> It seems to me (late on a Friday to be fair), that without applicability
> rules your mappings are just "out there", when what they really need to do
> is connect to physical systems, so they must have some sense of units
> (maybe AST has some hidden mappings that need to be drawn out, the ones
> that Frames use to provide purified outputs for the mappings).
In a sense you are correct - Mappings by themselves *are* just "out
there". You need some way to specify what the input and output
coordinate systems are for a Mapping. In AST this is provided by the Frame
class. In the VO, it looks like Arnold Rots Space-Time-Coordinates schema
will play some part in it. But this is just how Rodney's TRANSFORM package
behaved. A TRANSFORM transformation was also just "out there" in that it
carried no informationm about the nature of its input or output coordinates.
Thanks for the comments.
David
|