<div dir="ltr"><div dir="ltr">Gerard/All,<br><br>Just attempting to separate Transform model discussion separate from the vo-dml Composition rule<br>Gerard&#39;s last mail with suggested model changes:<br>   <a href="http://mail.ivoa.net/pipermail/dm/2020-March/005994.html" target="_blank">http://mail.ivoa.net/pipermail/dm/2020-March/005994.html</a><br><br></div><div>1) What AST implements as Frame is modeled in the coords model.. <br></div><div>    The version coming out next (post RFC comments), uses CoordSys to combine the &quot;Frame&quot; and &quot;CoordSpace&quot; information which == ast:Frame<br></div><div>2) The Transform model has also been updated to include a &quot;SystemMap&quot; which references source and target coords:CoordSys with a trans:TMapping<br></div><div>    This has not been released on Volute, because David is working through the implementation thereof with AST to look for issues in compatibility with ast:FrameSet.<br><br></div><div>In the coords model, the visibility of individual axes is severely limited.  For the most part, our data reside in standard coordinate spaces, and the specific axes (other than Pixel), are rarely explicitly defined.  So the AxisMap design doesn&#39;t, I think, play well with the typical data product.  <br><br></div><div>I also don&#39;t see that supporting the compound mapping, though it may be modifiable to do so.<br></div><div>The scenario for the compound mapping is something like<br></div><div><span style="font-family:monospace">     Frame A  (x,y) ==&gt; [ shift ] =&gt; [scale]  =&gt; [Permute] =&gt; | Poly2D | =&gt; (X&#39;,Y&#39;) Frame B<br></span></div><div><span style="font-family:monospace">                                                              | Poly2D |<br></span></div><div><span style="font-family:monospace"><br></span></div><div>With a similar set of operations for the &#39;inverse&#39; path.  There is no &quot;Frame&quot; spec between each individual operation.<br><br></div><div>Mark<br><br></div><div dir="ltr"><br></div></div>