I'm starting to warm up more to a specialized feature linked to the audit log (option 2) with all the arguments made here. It sounds like "for each change made on form re-entry, gather an alphanumeric user identifier and free text comment" is a very common requirement and narrowly addressing that case in a way that is easy for form designers would provide a lot of value. We could write a spec that describes what pieces of information need to be gathered from the user, when the user is required to enter them, and where in the audit log they get written to. Clients could choose an appropriate presentation.
If we had existing full-featured XForms engines to work with, there would be lots of interesting options but we don't and the XForms-y solutions I've come up with are either a ton of work for little marginal user benefit, not a great user experience, a bit of a hack, or a combination of the former.
Agreed the specs for for
and the comment
appearance look good. When those comments are used to track reasons for change, is there something that forces the comments to be filled in? Is user identity tracked based on who is logged in to a server?
I do think that for our users, separating the form data that and the audit metadata is valuable. It's not always the same people who analyze the two and working with XML is generally a higher technical bar. All that to say, if something like the for
bind attribute were used for this purpose, I think the servers would have to do additional steps to extract the audit information. Given server fragmentation, I would say that's less than ideal.
Similarly, regarding the form design side, @martijnr wrote
That doesn't feel particularly more flexible than a single attribute that magically requires comments on all fields.
What I'm most nervous about are follow-on requirements like coded (rather than free-form) reasons for change.