Remove epoch propagation and cleanup for WD

[tomdonaldson]

This PR removes the proposal to use new COOSYS subelements for epoch propagation which was added in PR #40. Preserved from that PR are:

• the new Makefile target test which uses stilts to validate the standalone file VOTable examples
• the new VOTable version 1.5 available in the xsd

In addition, the following changes were made to prepare for the next working draft:

• Added a refposition to <COOSYS> in the timesys_example.vot. This seemed like a good idea since I noticed that prior updates inadvertently dropped refposition from COOSYS in the xsd
• Updated the diff section from 1.4 to 1.5 (resolves Review section 9.4 (Differences Between Versions 1.4 and 1.5) #46)
• Updated the attribute diagram in section 7.2 to include refposition in <COOSYS> (resolves Update sections 7.1 and 7.2 to match schema changes for COOSYS #41)
• Updated the schema version to be 1.5 without any "pre"

[msdemlei]

Looks reasonable -- thanks for doing all that work.

It's still a bit of a pity because we'd finally have automatic epoch propagation, but in the interest of getting 1.5 out of the door, then be it.

[mbtaylor]

Tom, all looks in order apart from the two small commits I just added and one other thing: should the VOTable.vor record be updated at this stage for v1.5? Or maybe that happens nearer the REC. Maybe @msdemlei can comment on that.

[msdemlei]

On Fri, Oct 20, 2023 at 02:25:08AM -0700, Mark Taylor wrote: added and one other thing: should the VOTable.vor record be updated at this stage for v1.5? Or maybe that happens nearer the REC. Maybe @msdemlei can comment on that.

If you're 99% sure that the schema won't change in RFC, having v1.5 in the XSD is all right. If not, I'd vote for leaving it tagged; it's not the end of the world if two VOTable XSDs with ***@***.***="1.5" float around, but it's not pretty either.

[tomdonaldson]

On Fri, Oct 20, 2023 at 02:25:08AM -0700, Mark Taylor wrote: added and one other thing: should the VOTable.vor record be updated at this stage for v1.5? Or maybe that happens nearer the REC. Maybe @msdemlei can comment on that.
If you're 99% sure that the schema won't change in RFC, having v1.5 in the XSD is all right. If not, I'd vote for leaving it tagged; it's not the end of the world if two VOTable XSDs with @.***="1.5" float around, but it's not pretty either.

I'm seeing 2 separate, but related things here. When should we update VOTable.vor, and what version should I put in the schema now? I take Markus' point on the schema, so I can update that to 1.5pre3 I guess. In preserving the history of the multiple versions, I can restore the original comment for 1.5pre1 as well.

My thinking on the vor file was that that would get updated when building the REC. I'm happy to be corrected on that.

[tomdonaldson]

On Fri, Oct 20, 2023 at 02:25:08AM -0700, Mark Taylor wrote: added and one other thing: should the VOTable.vor record be updated at this stage for v1.5? Or maybe that happens nearer the REC. Maybe @msdemlei can comment on that.
If you're 99% sure that the schema won't change in RFC, having v1.5 in the XSD is all right. If not, I'd vote for leaving it tagged; it's not the end of the world if two VOTable XSDs with @.***="1.5" float around, but it's not pretty either.

I'm seeing 2 separate, but related things here. When should we update VOTable.vor, and what version should I put in the schema now? I take Markus' point on the schema, so I can update that to 1.5pre3 I guess. In preserving the history of the multiple versions, I can restore the original comment for 1.5pre1 as well.

My thinking on the vor file was that that would get updated when building the REC. I'm happy to be corrected on that.

@msdemlei are you comfortable with the updated schema version and the unchanged state of VOTable.vor?

[msdemlei]

On Fri, Oct 20, 2023 at 08:04:03AM -0700, Tom wrote: > My thinking on the vor file was that that would get updated when building the REC. I'm happy to be corrected on that. @msdemlei are you comfortable with the updated schema version and the unchanged state of VOTable.vor?

Yes... that actually sounds like a very good idea.