Re: [legaldocml] Redlining Discussion Slides and Background Info

It seems that XMetaL, Xopus, and Oxygen all take the processing instruction approach - but none in a standard way. I agree that there should be some standard representation that is editor neutral and allows for data interchange and can last for much longer than the lifetime of any particular editor. It's a general subject that is much broader than Akoma Ntoso. I'm still looking around to see if anyone has tackled this.

A related issue that should be solved in a similar manner is page and line number handling. We also address this with processing instructions, by back annotating the source document with page and line number PIs during the publishing process. As the PDF is generated using XSL-FO, we use a hook to edit the input stream. The result allows us to reference page and line numbers, doesn't pollute the schema, and is very flexible. But again, it's a proprietory solution.

On Wed, Oct 24, 2012 at 2:02 AM, Thomas R. Bruce <tom@liicornell.org> wrote:

On 10/24/12 3:34 AM, Grant Vergottini wrote:
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.

===

Grant:
This makes perfect sense to me. I wonder if we might create a related schema that could be used to describe the syntax of the proprietary solutions in a standard way -- that is, an interchange standard for processing instructions, such that someone porting could use it to transform PIs from one system to PIs that would work in another. Wouldn't have to be part of AKN, necessarily. But very handy for systems/practice communities that make different assumptions about the granularity of edits and their implicit merging behavior. I suspect that numbering practices in the shadow of insertion would raise similar issues ...

t.

--
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
Thomas R. Bruce @trbruce
Director, Legal Information Institute
Cornell Law School
http://www.law.cornell.edu/ @liicornell
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

legaldocml message