Property1D/2D model elements.

[mcdittmar]

These comments are on version (commit 27c4bd3) and relate to #53 and #51.

PropertyError1D specific.

1. Figure 4: as DataTypes the contents of EpochPositionErrors should be represented as attributes rather than compositions.
2. PropertyError1D: PropertyError1D to be renamed as Symetric1D #53 moved this to be Symmetric1D, and Asymmetric error support #51 adds Asymmetric1D, so there are 2-1D error types that could reside at the RadialVelocity and Parallax attribute. Keeping with the model layout, this should have made PropertyError1D abstract, with the 2 subclasses for Symmetric1D and Asymmetric1D.

However.

1. In working the Meas.model, these 'abstract dimensional grouping' types were dropped because the general consensus was that they created more complication than they were worth.. So, I'd actually suggest that you drop Property1D/Property2D entirely and make the error types directly extend PropertyError, similar to what is done in the Meas. model with meas:Uncertainty.

[lmichel]

Figure 4: as DataTypes the contents...

OK

PropertyError1D...

The model design was driven by serialization considerations.
As I understood from the @mbtaylor feedback in Sydney, it is easier for clients to deal with an error block that hosts all error roles of the EpochPosition parameters.
This was the motivation for not attaching errors with their individual parameters.

In working the Meas.model, these 'abstract dimensional grouping'

This dimensional grouping has been set t make sure that a 2D parameters will have a 2D error.
If we remove it, the model becomes simpler, but with the risk of inconsistency.
I'm OK for removing this dimensional grouping if people think that inconsistency is not an issue.

[lmichel]

Figure 4: as DataTypes

Done in #62

In working the Meas.model, these 'abstract dimensional grouping'

Done in #62: no longer 'abstract dimensional grouping'