Use cases and requirements
Use cases and Requirements
I would like a simple "do and propose process". Here are the step
- People send an email with a proposal for this use case and requirements
- they copy paste a small version of this proposal with a link to the email send
- for each use cases and requirements we record the number of support versus objection
When a document is edited in an XML-aware editor, the changes that are made may need to be tracked. Typically, an XML editor will validate the document in some way, and this should still be possible even with change tracking present. The way that this is commonly achieved is to encapsulate the change tracking in processing instructions so that the final version of the document can be validated if these processing instructions are ignored.
If two XML documents are compared, then it should be possible to represent the differences between these two documents using the change tracking format. It is preferable in this situation that the representation of the changes are in an XML markup format, so that they can be processed using standard XML processing languages such as XSLT. As an extension to this, it should be possible to show the changes between not only two versions of the document, but multiple versions of the document, where each version represents one or more changes from a previous version. In other words, the versions have some order, which is typically a time order.
Transmission of changes
It is sometimes useful to be able to communicate changes to an XML document without including the whole of the XML document itself. This is particularly useful in situations where the original document is very large, and the changes are quite small. Therefore it is useful in this situation to have a representation of changes in a form that is independent of the original document.
NOTE: This begs the question of the sense of direction of change tracking. Typically, change tracking represents changes that have been made to a document in the past, and can be undone to get back to an earlier version of the document. There seems to be no fundamental reason why change tracking could not also represent changes that need to be made to a document to move it to a new version.
1. There shall be a representation of tracked changes that does not interfere with the validation of the final version of a document.
2. There shall be a representation of changes using XML markup.
3. There shall be a representation of changes that is independent of the document that has been changed.
4. It must be simple to strip all the tracks changes out of the document in such a way that the result is the final version of the document.
5. It shall be possible to reverse the sense of the track changes, so that instead of representing change that has been made to the final version of the document, it can represent change that needs to be made to a document moving forward, i.e. to move to a new version of a document.