Data Provenance (DPS) TC

I propose markdown be the official format of both Committee Specs (metadata, use cases). OASIS specs are published in multiple formats, but one of them has to be the official spec (and the other formats are then derived from the official one). I think we've agreed to use GitHub for drafting the text. Markdown marries very well with GitHub as markdown is just text. Markdown does mean you can't get as fancy as you can with Word or GoogleDoc. I consider that an advantage of markdown, not a drawback.Technically markdown can get as fancy as HTML (since you can embed HTML) but I recommend strongly against getting fancy.  If someone is not familiar with markdown, there are plenty of online tutorials. I'd also be willing to 1:1 with people who would like an introduction. We started using it many years ago in a TC I was involved with and it initially met a lot of resistance until people actually used it and then they preferred it. I hope we are over that nowadays.

Note the editors are the ones stuck with a lot of busy work associated with specs, so they should get a say. My belief is that markdown is 'easiest' (which doesn't mean easy) for the editors since (1) it's easy to read the raw markdown (2) it's easier change control (ie GitHub tracks changes in markdown better than html or doc) and (3) many TC's use markdown as official and have the tools to convert markdown to the other formats.

Markdown does have the disadvantage that it's not as easy for realtime shared collaboration as something like googledoc. My experience has been that 'shared drafting' doesn't happen that often and the benefits of markdown outweigh the drawbacks.

If people want to argue for a different format, please reply with your reasoning.

I propose markdown be the official format of both Committee Specs (metadata, use cases). OASIS specs are published in multiple formats, but one of them has to be the official spec (and the other formats are then derived from the official one). I think we've agreed to use GitHub for drafting the text. Markdown marries very well with GitHub as markdown is just text. Markdown does mean you can't get as fancy as you can with Word or GoogleDoc. I consider that an advantage of markdown, not a drawback.Technically markdown can get as fancy as HTML (since you can embed HTML) but I recommend strongly against getting fancy.  If someone is not familiar with markdown, there are plenty of online tutorials. I'd also be willing to 1:1 with people who would like an introduction. We started using it many years ago in a TC I was involved with and it initially met a lot of resistance until people actually used it and then they preferred it. I hope we are over that nowadays.

Note the editors are the ones stuck with a lot of busy work associated with specs, so they should get a say. My belief is that markdown is 'easiest' (which doesn't mean easy) for the editors since (1) it's easy to read the raw markdown (2) it's easier change control (ie GitHub tracks changes in markdown better than html or doc) and (3) many TC's use markdown as official and have the tools to convert markdown to the other formats.

Markdown does have the disadvantage that it's not as easy for realtime shared collaboration as something like googledoc. My experience has been that 'shared drafting' doesn't happen that often and the benefits of markdown outweigh the drawbacks.

If people want to argue for a different format, please reply with your reasoning.