Solid

I don't really understand this issue. Could you please clarify a bit what it is you're suggesting there? -J

The 2 letter markers used in dictionaries are not particularly clear in their meaning. So I think the suggestion is to have a fuller text representation of what the marker actually is, and also indicate if it is 'standard' MDF marker vs a user defined marker.

Ah, thanks. That makes sense to me now.

Personally, I think it should be an editable "Description" field that typically contains the MDF name and description associated with a marker. But as groups create their own templates (A.J. is doing so for PLB right now), which may or may not be "MDF" derivatives, they'll want to describe their "standard" fields too. And even custom fields--especially custom fields--need to be documented.

Using a consistent label in all the MDF fields should be sufficient to distinguish them from other fields, and if the user deliberately edits the description of an MDF field, well, let it be on the user's head. At least, that seems consistent with the overall (customizable) approach Solid takes. We already do let the user re-arrange hierarchy and change marker rules.

To be even more specific:

When you double click a field in SOLID, in the dialog that pops up for you to configure that field, there is a tab "Mapping". If you click on that tab, you can define what that field maps to. There is a combo box that lets you choose certain "targets". So far it is LIFT and FLEx (and the FLEx one doesn't work). If you choose one of these targets, a lot of the mapping targets get filled in. This would be useful if you were actually doing an export from SOLID into one of these other formats, but for now I think exports don't work. But it would still be helpful for analyzing an MDF file.

So my interpretation is that John wants MDF added as one of those targets, and it would be the initial target that was on by default.

Is that somewhat close?

Actually, no, I what this issue is asking for (which I wrote in more detail via email but Redmine seems to have ignored), is a column in the field list which simply tells me the value of the field if it is found in the MDF standard. Beth's comment reminds me that we should just remove the FLEx target; but then, maybe enhance the LIFT target to include common FLEx values? We would of course clearly label them so that people know that what they are getting is a custom LIFT field, but with a name that means FLEx will import it into the proper FLEx field.

Yes, John, I agree absolutely that we a better-streamlined linkage between MDF and FLEx. The number of fields in the LIFT list are just too few compared to MDF and FLEx.

But I also think that there needs to be a user-editable description for each field. So, sorry if I've accidentally piggybacked on a separate issue, but I think they're somewhat related issues--the user needs to be able to clearly describe or link to a clear built-in description of each field.