Wrestling with a JLIFF serialization of glossary data

[Chase Tingley <chase@spartansoftwareinc.com>]

I'm going to start with the example from section 5.2.6 of XLIFF:

   <unit id="1">
     <gls:glossary>
       <gls:glossEntry ref="#m1">
         <gls:term source="publicTermbase">TAB key</gls:term>
         <gls:translation id="1" source="myTermbase">Tabstopptaste
         </gls:translation>
         <gls:translation ref="#m2" source="myTermbase">TAB-TASTE
         </gls:translation>
         <gls:definition source="publicTermbase">A keyboard key that is
             traditionally used to insert tab characters into a document.
         </gls:definition>
       </gls:glossEntry>
     </gls:glossary>
     <segment>
       <source>Press the <mrk id="m1" type="term">TAB key</mrk>.</source>
       <target>Drücken Sie die <mrk id="m2" type="term">TAB-TASTE</mrk>.
       </target>
     </segment>
   </unit>

This is hierarchical data, and it's fairly easy to imagine a straightforward conversion to something like this:

"glossary": [
    {
        "ref": "#m1",
        "source": { "text": "...", "source": "publicTermbase" },
        "translations": [
            { "id": "1", "source": "myTermbase", "text": "..." },
            { "ref": "#m2", "source": "myTermbase", "text": "..." },
        ],
        "definition": {
            "source": "publicTermbase",
            "text": "..."
        }
    }

} 

I'm not having much luck doing better than this, though.  In particular, I wanted to try promoting the value of the "ref" attribute up to be an object key, like this:

"glossary": {

    "#m1" : {

        "source": { "text": "...", "source": "publicTermbase" },

        "translations": [ .... etc ] } }

Unfortunately, "ref" is an optional attribute, so this scheme breaks down.  Similarly, within "translations", some translations are keyed by "ref" and some by "id", so again the flexibility of the module sabotages a simple serialization.

As I mentioned on the call yesterday, I have some hopes that we can the common module pattern of decorating core data by reference to help encode some types of module data (like SLR) into standoff sections.  But here, at least, that doesn't seem to be working.