[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [legaldocml] Redlining Discussion Slides and Background Info
“it does not necessarily mean that this is a change from a previous version of a bill. Instead it is information about how the amended section actually differs.”
I’m losing the thread of your argument here. If this shows “how the amended section … differs” from a previous version, why is it not “a change from a previous version”?
Can you bring an example of some redlining strike or insert that illustrates this point?
From: firstname.lastname@example.org [mailto:email@example.com]
On Behalf Of Grant Vergottini
Here is a list of issues I would like to discuss during the TC meeting today. It's a follow-on from my previous presentation a number of weeks back on the subject. Hopefully we can start closing some of the issues I have come up with:
1) Redlining shown within an active modification. For example, in California all amendments to codes are always complete sections. It is not permitted to amend just a word or sentence. The old section must be replaced with a new section, even when the change is just a few words. This makes it clearer to the legislators what is being proposed. To make it even clearer, they show the words within the section that are actually changing using strikeout and insert notation. But this is informative redlining and does not correspond directly to either active or passive redlining. When you see this notation inside a section being amended inside a bill, it does not necessarily mean that this is a change from a previous version of a bill. Instead it is information about how the amended section actually differs.
2) Merge/Split paragraphs. I believe there is now a mechanism to handle this. I saw mention of it a few weeks ago. I'm not clear of the details. In my case, the redlining notation used can be separated from the actual modification recorded as a modification. The redlining reflects what the change is according to local custom instead of literally containing the change. This is what Fabio said and I agree with him.
3) Complex edits. This is a difficult subject. In California, it is quite common for edits to be made that violate the XML hierarchy. For example, two bill sections might merge into one by striking the second half of the first bill section and the first half of the second bill section. The drafter then assumes that the two remaining halves will make a single joined together section. This makes no sense from an XML point of view, but makes total sense if you're a drafter and only care about the paper.
When we build the California system, we tried to argue that this practice had to change. We were told that we had to support one way or another. This was not negotiable. Our solution was to rely on XMetaL's change control mechanism which records deletions inside processing instructions and insertions bounded by two processing instructions and to write some very complex software to magically glue bill sections together when this sort of situation arose. And the scenario I outlined is the simple case - there are much more complex scenarios involving heading levels in more complex documents.
But the solution I used relied on the builtin change control mechanism that was built independent of our schema. With this approach we were able to handle all the possible scenarios without having to pollute the schema with lots and lots of "choices" to allow deletions and insertions to be placed anywhere in the document. I think that this solution was the only way I could have solved the problem. If I had tried to invent some other mechanism that avoided XMetaL's builtin processing instruction solution, the complexity of the problem would have made solving it impossible in an editing environment. So I don't think that trying to find a solution for this within Akoma Ntoso is a good idea. It is better to rely on the intrinsic (builtin) change control that the editor provides. The biggest drawback though is that the insert and delete markings become proprietory solutions for a particular editor using processing instructions that are only understood by that editor and the solution built around it.
4) I believe that I can map all other redlining scenarios into Akoma Ntoso with little problem. Related to this subject is our amendment practices which is page and line number oriented. That is how it is done in virtually all US jurisdictions and it's not likely to change soon - page and line numbers are here to stay. But, like redlining, we have solved this problem without affecting the schema and I would propose that we not encumber the schema with page and line number issues.
On Tue, Oct 23, 2012 at 11:40 AM, monica.palmirani <firstname.lastname@example.org> wrote:
Associate professor of Legal Informatics
School of Law
Alma Mater Studiorum Università di Bologna
Palazzo Dal Monte Gaudenzi - Via Galliera, 3
I - 40121 BOLOGNA (ITALY)
Tel +39 051 277217
Fax +39 051 260782