XMetaL annoyance: validation of mulitple instances of and IDREF to a missing ID

[dcramer]

This has bugged me for a long time (and I don't recall if I've already mentioned it to XMetaL support).

In XMetaL up to 5.5 at least, if you have a document with a more than one crossreference element (i.e. one that has an attribute of type IDREF like DocBook's xref) to the same target ID and that ID is missing, when you validate the document, XMetaL reports one validation error that links to the first bad crossreference.

The usability of this is terrible. Often when refactoring a doc you end up with several bad crossreferences to the same target ID. You have to fix each, then validate again, till you've reached the last. It's easy to forget that XMetaL doesn't give you all the errors at once, so you validate, fix the first bad xref, then commit to your repository, only to have your document fail to build (I have validate on save off).

XMetaL should report all the bad crossreferences at once or at least indicate that an error has mulitple instances. 

Thanks,
David

Reply

[Derek Read]

I will log this as a feature request, however, given that it would not affect very many people this will probably be classified as lower priority than the other features we are working on.

Reply

[Derek Read]

I've thought about this a little bit more. You could perform an additional check and add additional messages to the Validation Log using script.

Another option would be to provide a form or toolbar (with scripts attached) that deals specifically with missing id values and perhaps guides the user with buttons to move to previous or next IDREF and/or ID, providing some means of copying a given IDREF value into an ID?

Or perhaps if you really want to go nuts a list of IDREF values on one side of a form (with some means to identify them, perhaps some portion of the PCDATA from their element), then a list of elements that don't have ID values but that should (if you can figure that out). I could then imagine a UI that would let you copy a value from the IDREF side to one of the items on the ID side, and perhaps vice-versa, then all of this would be set when the form is closed. What about elements that have an IDREF value that isn't set that should be? Or is that a real case?

Or keep reminding the user whenever they save that their document is invalid, but then we're sort of back to the fact that validation is turned off during save in your setup, so I guess this last one doesn't really help, except that you might provide a different nag screen that only shows missing IDs?

The requirements seem to be fairly unique: allow invalid documents to be saved, except that all IDREF attributes must have a matching ID — so that part of the validation must pass but anything else is let through.

Reply

[dcramer]

Ok, let me clarify: What I think XMetaL should do is list all the bad IDREFs in the validation report.

I'm guessing that the current behavior is based on the assumption that if there are multiple bad IDREFs to the same ID, the solution is to add an ID, so there's really just one problem. But in fact, you often get these because you've removed a target permanently and now need to go find all the places that refer to it and remove the reference. In XMetaL you validate, click to navigate, fix, revalidate, click to navigate, fix, and so on. What I end up doing is opening the document in emacs, validating, fixing all the IDREFs, then going back to XMetaL.

Validate on save doesn't really fix this but does at least remind you that you still have more bad IDREFs. However, I have validate on save turned off because I've had problems with XMetaL crashing on validate before and so don't want a user to hit save, only to have it crash and lose what they were trying to save.

David

Reply

[Derek Read]

I will log this feature request as described, however, I suspect that if it is possible to implement this feature it will not be done soon.

Reply

[Author]

Posts