Minor Proposed Change to File History

[Xander9009]

So, I've been a bit displeased with how the system I set up for editor history has aged. It's not very robust, though it's certainly simple. I was considering what issues it has and how they might be addressed. The main two issues are:
1: When there are a lot of editors/edits, it becomes difficult to match edits to dates.
2: When there's a comment, the current method of including those comments isn't very well incorporated.

I whipped up this from a card with those issues (Raging Ravine).

Code: Select all

<AUTHOR><![CDATA[sumomole]]></AUTHOR>
<EDITORS><![CDATA[sumomole, Borborigmos, Splinterverse, Splinterverse, Splinterverse, Splinterverse]]></EDITORS>
<DATE><![CDATA[25-09-14, 23-10-15, 16-01-17, 22-01-17, 29-01-17, 03-02-01]]></DATE>
--22-01-17: Added availability block to creature ability.

Becomes   

<HISTORY>
   <CREATION Author="sumomole" Date="25-09-14" />
   <EDITS>
      <EDIT Author="Borborigmos" Date="23-10-15" />
      <EDIT Author="Splinterverse" Date="16-01-17" />
      <EDIT Author="Splinterverse" Date="22-01-17"><![CDATA[Added availability block to creature ability.]]></EDIT>
      <EDIT Author="Splinterverse" Date="29-01-17" />
      <EDIT Author="Splinterverse" Date="03-02-01" />
   </EDITS>
</HISTORY>

It would also handle multiple people in one field much better. As an example, for multiple creators:

Code: Select all

<AUTHOR><![CDATA[sumomole, Borborigmos]]></AUTHOR>
<EDITORS><![CDATA[sumomole, Borborigmos]]></EDITORS>
<DATE><![CDATA[25-09-14, 23-09-14]]></DATE>

Becomes

<HISTORY>
   <CREATION Author="sumomole" Author2="Borborigmos" Date="25-09-14" />
</HISTORY>

Thoughts? Suggestions? How could this be improved? Should I just leave it as it is?

[RiiakShiNal]

One thing to note is that XML attributes don't handle non-roman characters very well (can't use CDATA there). If no one is using non-roman characters for their name then it isn't a problem, but if you want to allow that then you should probably adjust it to be something like this:

Code: Select all

<HISTORY>
  <CREATION Date="25-09-2014">
    <AUTHOR><![CDATA[sumomole]]></AUTHOR>
  </CREATION>
  <EDITS>
    <EDIT Date="23-10-2015">
      <AUTHOR><![CDATA[Borborigmos]]></AUTHOR>
    </EDIT>
    <EDIT Date="16-01-2017">
      <AUTHOR><![CDATA[Splinterverse]]></AUTHOR>
    </EDIT>
    <EDIT Date="22-01-2017">
      <AUTHOR><![CDATA[Splinterverse]]></AUTHOR>
      <![CDATA[Added availability block to creature ability.]]>
    </EDIT>
    <EDIT Date="29-01-2017">
      <AUTHOR><![CDATA[Splinterverse]]></AUTHOR>
    </EDIT>
    <EDIT Date="03-02-2001">
      <AUTHOR><![CDATA[Splinterverse]]></AUTHOR>
    </EDIT>
  </EDITS></HISTORY>

Code: Select all

<HISTORY>
  <CREATION Date="25-09-2014">
    <AUTHOR><![CDATA[sumomole]]></AUTHOR>
    <AUTHOR><![CDATA[Borborigmos]]></AUTHOR>
  </CREATION>
</HISTORY>

Multiple authors for an edit would then simply be multiple AUTHOR blocks in the EDIT block (no need for adding numbers to the block/attribute name).

Optionally, you could put the comment in a COMMENT block to better document it in the file.

Code: Select all

<COMMENT><![CDATA[Added availability block to creature ability.]]></COMMENT>

Also I recommend 4-digit years in the dates as it makes it somewhat easier to figure out what order it is in (personally I prefer YYYY-MM-DD since for automatic sorts it makes things really easy even when it is just a string sort).

[Xander9009]

Will definitely do the year as YYYY-MM-DD; that makes a lot of sense. The authors using CDATA blocks makes sense, and I'll do it that way, though I did list out the authors currently involved and there aren't any characters to worry about. That said, the whole idea is to be more robust and future-proof, so... I really like the idea of the comment block, especially if the authors are getting a separate tag instead of simply being an attribute.

Good ideas. Thanks.

I'll give it a few days to percolate in case anything else comes to mind for anyone (not to mention I don't currently have the time needed to write a script to swap everything to the new version, anyway). I'll probably implement whatever changes are finalized on Monday unless they're still being discussed.

I'm also considering reworking the uploading process so that the tool I'm working on can handle the uploading of new files. If I do that, I could incorporate a small section to handle writing out the history for you instead of having to do that by hand, so anything that makes the history easier to parse without sacrificing human-readability is good.