RE: [courtfiling-doc] Marking up narrative text in court documents using the JXDM

["Rolly Chambers" <rlchambers@smithcurrie.com>]

I think I'm the source of confusion. See comments below.

Thanks for the responses.

R Chambers

________________________________________
From: John Messing [mailto:jmessing@law-on-line.com] 
Sent: Thursday, March 09, 2006 1:05 PM
To: Chambers, Rolly
Cc: courtfiling-doc@lists.oasis-open.org
Subject: RE: [courtfiling-doc] Marking up narrative text in court documents
using the JXDM

<snip/>. 
As I understand the effort you have undertaken, it is to take what looks 
like an intermediate type of text, which occurs primarily in forms, and 
create extensions of categories in GJXDM to accommodate such text 
because it is reusable. My inquiry is whether such categorization 
breaks down when humans decide the form needs to be revised, which 
often happens for example with immigration forms. If new text is added 
and old text deleted, or substitute text is put into a portion of the 
document that changes the meaning to human readers, then the text is 
not really being re-used. Re-usability is only a consideration where 
text remains immutable. So, how much work is involved is going to be 
involed each time to see if a new category has been created, or a 
different category must be used, or the like, if such extensions are 
put into practice? 
I hope this is clearer. 

[RC - I think my earlier use of the term "extension schema" created
confusion. I should have referred to a "document schema" instead. 

I was looking at the "boilerplate" narrative text (the printed text in paper
forms) in fill-in-the-blank-type court documents and wondering whether the
GJXDM includes elements to mark up such text. I understood the GJXDM
includes elements that can be used to mark up the data elements (the blank
spaces in paper forms), so I wasn't particularly worried about data
elements.  However, if the GJXDM did not contain elements for marking up
boilerplate narrative text, then there would not be a way for a single XML
instance to include and display the boilerplate along with the data items.
Absent the boilerplate narrative text, a GJXDM XML document would be fine
for data exchanges by machines. For display to people, however, the
boilerplate text would have to be added via a generic text element or other
markup from outside the GJXDM, added by an external style sheet or in an XML
comment, or as is currently done be added as a pdf or other attachment.

All I did was create a subset of a few dozen types (or "objects") and
elements (or "properties") from the GJXDM and then create a document schema
using only those subset types and elements. In the document schema, I
created a document root element (plus a signer element) and then imported
various GJXDM types and elements from the subset to create the document
content models. This is consistent with the process for creating document
schemas for IEP's as described in the Global XML User's Guide. In short,
while the root element and signer element in the examples in a sense are
"extensions," they actually contain only elements from the GJXDM. In that
regard, I did not create extensions of GJXDM categories -- I just used what
is already there.

I do not foresee frequent changes to the boilerplate text in form documents.
Once such text is marked up with an appropriate GJXDM element, I don't
expect a document author to change the boilerplate in the form. The document
author certainly would input data into the data entry fields (e.g. names,
dates, times, etc.) and the form processing application would output all the
content, data items and boilerplate text together, in a single GJXDM
document instance. A more likely problem is that I might mistakenly enter a
person's first name (e.g. James) in the field for their surname. I don't
know how any schema can protect against this kind of error or
miscategorizing.

A law firm or bar association forms committee or an IEP task group might
change the categorization of the boilerplate text in a form at some point.
However, I don't think such a change would require major re-writing or
re-work of processing applications (although this probably depends on the
particular processing application involved).

Rolly