OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

courtfiling-doc message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

Hi Rolly,

   Thank you for the comments and examples.  I agree with you that this
is a likely possibility.  This was breached to an extent on the last
conference call with the discussion about using the structure of:

	\_ Qualifier

to mark up the text of documents.  This is a concept somewhat found in
GJXDM and to an extent is used more in NIEM.  I have reservations about
using this concept with GJXDM and this was one of the reasons for using
the stylesheet for text.  In GJXDM, many of the "DescriptionText"
elements have specific semantic meanings which are more similar to an
unstructured use of codes than on allowing for the use of free form
text.  For example, in the Arizona subpoena example,
"CourtOrderServiceDescriptionText" is defined as a "description of how a
court order was delivered" and can be codes or free form text to
describe the methods used to serve the document, such as personal
service, tack and mail, or other means.  

  Currently, Michael Alexandrou is working on marking up a full Child
Support Order using NIEM 0.2.1, similarly to the markup of the Arizona
documents.  Using NIEM, there is a way to mark up the court order
conditions by giving each an id (for machine processing), a type (for
categorization), and a text (for human readable consumption) with what
looks to be relatively little to no extension needed.  There is also a
way, with minor extension to give sub qualifiers to the court order
condition, such as a time limit for reporting or an amount for payment.

  Using GJXDM, we had to make extensions that were akin to major surgery
on the schemas to fit text that could be reused in both an automated
workflow and a human readable version into the xml instance due to the
areas that needed extension being located at a semantically deep path in
the XML instances.  This same task, so far, has been going well with the
use of NIEM, due to its more flexible structure, but we are only
starting out with its use.  As soon as we know more if this method will
work or not, we'll post some results and information from the Child
Support Order.

  In summary, I agree with the concept and the ideas.  The issues that
we have run into using this method have been ones of dealing with issues
with extensions.  There may be extension methods that we haven't learned
that may be able to correct these, but also changing to NIEM seems to
alleviate some of the issues due to its structure. 

  Have you run into any issues with extensions or otherwise in marking
up the Arizona documents?



-----Original Message-----
From: Rolly Chambers [mailto:rlchambers@smithcurrie.com] 
Sent: Thursday, March 09, 2006 10:27 AM
To: courtfiling-doc@lists.oasis-open.org
Subject: [courtfiling-doc] Marking up narrative text in court documents
using the JXDM

Rex, et al.

This is a long message. 

A while back I experimented with marking up a few simple court documents
using the JXDM. I wanted to see if the JXDM XML vocabulary could be used
markup narrative text information typically appearing in printed form
documents as well as the data items that have been its primary focus. I
figured if the JXDM provided reasonably adequate markup tags for the
narrative text in court documents, then by using an xslt/xslfo style
it would be possible to publish/display an XML court document instance
marked up using the JXDM. A single XML court document instance thus
contain both marked up narrative text and marked up data elements and
satisfy both uses -- publication/display for people and data
interchange/automated processing for machines. The same XML instance
that a
machine "reads" would be the same one that a person reads.

Court documents are a mixture of both structured data and narrative
text. I
continue to be concerned that placing narrative text in a style sheet
placing only the structured data elements in a xml instance separates
legally meaningful narrative text information, such as an order or a
from the associated data elements, such as a person's name and
info, the date, the case, the court, etc. Such a separation no doubt
sense from a data-centric perspective, but it is troubling from a
document-centric point of view. 

Assembling the contents of a human readable document from different XML
sources and outputting them in a single display document for human
consumption is technically viable. However, this approach raises issues
terms of information storage (how and where would all the different XML
sources be stored), information integrity (how would the integrity of
the different sources and the output document be secured), and reliance
applications to correctly associate the appropriate narrative text with
appropriate data items (how would the human readable document be
correctly if applications for associating the narrative text with the
elements become obsolete or unavailable). Placing the data elements and
narrative text into a single XML instance alleviates these concerns. 

Based on my initial experiment, I believe the JXDM XML vocabulary can be
used to markup up narrative text as well as data elements in simple
form-type court documents. The JXDM semantics work reasonably well for
narrative text components as well as for data items in such court
Attached are five "proof of concept" XML instances (two subpoenas, two
warrants, and a show cause order) marked up using the JXDM. These
illustrate one way that JXDM elements can be used to mark up all the
information contained in simple paper court documents -- both the data
elements and the meaningful, legally significant narrative text. 

In general, I followed the process for creating JXDM document schema for
IEP's. First I created a subset of JXDM elements and attributes that I
wanted using the Subset Generation Tool. Then I created an extension
for the document. As I experimented, I went back to modify the subset
time to time. I did not focus on the data modeling step for creating an
because that step is more important for identifying data elements in
designing document schema for data interchange than for identifying text
elements. The data modeling step is important -- I just didn't need to
on it for the "proof of concept" experiment. I was more concerned with
narrative text parts of a court document and the JXDM elements available
marking up narrative text. If you are interested, I can provide the
schema I came up with.

To make sure I included appropriate narrative text in the example
I worked from .pdf versions of paper form documents from Maricopa
Arizona. John Messing had sent them to me a few months ago and they were
simply handy for purposes of the experiment. The Arizona court document
forms are substantially similar to those used in North Carolina and
to the forms used in Georgia and other states as well. 

The main thing I discovered is that there are JXDM elements that can
as reasonably adequate containers to describe the narrative text in
form-type court documents such as subpoenas, warrants, etc. This means
all the information in form court documents, both data elements and
narrative text, can be marked up using the JXDM and combined in a single
instance. The data elements can be exchanged and processed by machines,
the same contents can be displayed or printed for human consumption. My
results are similar in many ways to the sample protective orders that
Leff and his students created a few months ago. The principal difference
that those examples place the narrative text inside XML comments, which
create issues for some XML parsers and for using xslt/xslfo style sheets
display the information, while I have placed it in JXDM elements.

One implication is that during the data modeling step in creating an
someone familiar with the narrative text in various form court documents
should be involved to make sure that narrative text types and elements
the JXDM are included in the data model along with the appropriate data
elements. This assumes, of course, that the goal is to create a document
model for XML instances that will be displayed and published for human
consumption as well as exchanged and processed by machines.

There were some quirks. The JXDM does not permit the sequence or order
elements to be changed. Thus the better approach is to structure the
information in the documents such that the narrative text comes first
"YOU ARE HEREBY SUMMONED to appear before this Court to answer the
Complaint at") followed by the appropriate data elements containing the
designated date, time, location, etc. A few times I needed to slightly
the sequence of the information in the printed forms to better match the
sequence/order of elements in the JXDM. The variances, however, were not

If you want more details, let me know.


Rolly Chambers

This e-mail and any files transmitted with it are intended solely
for the use of the entity or individual(s) to whom they are
addressed and not for reliance upon by unintended recipients.  If
you are not the intended recipient or the person responsible for
delivering the e-mail to the intended recipient be advised that you
have received this e-mail in error and that any use, dissemination,
forwarding, printing, or copying of this e-mail and any files
transmitted are strictly prohibited. If you have received this
e-mail in error please delete the entire email and immediately
notify us by email to the sender or by telephone to the AOC main
office number, (404) 656-5171. Thank you.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]