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


This is an immensely useful way of proceeding, but it raises the issue
for me whether narrative text in court documents needs anything more
than a generic "human readable text" placeholder element rather than
granular schema extensions since such text is for the benefit of human
readers and at least at this stage has no function for "smart" machine
actions. While for lawyers and judges the text often is the meat of the
matter, for processing purposes such text is often inert blocks of
information that is simply sent to a graphic user interface as text in
a form comprehensible to the human reader.

It could simply the mark-up task considerably if the suggestion is
viable upon reflection.

> -------- Original Message --------
> Subject: [courtfiling-doc] Marking up narrative text in court documents
> using the JXDM
> From: "Rolly Chambers" <rlchambers@smithcurrie.com>
> Date: Thu, March 09, 2006 8:26 am
> To: <courtfiling-doc@lists.oasis-open.org>
> 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 to
> markup narrative text information typically appearing in printed form
> court
> 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
> sheet,
> it would be possible to publish/display an XML court document instance
> marked up using the JXDM. A single XML court document instance thus
> could
> contain both marked up narrative text and marked up data elements and
> would
> 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
> and
> placing only the structured data elements in a xml instance separates
> the
> legally meaningful narrative text information, such as an order or a
> waiver,
> from the associated data elements, such as a person's name and
> identifying
> info, the date, the case, the court, etc. Such a separation no doubt
> makes
> 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
> sources and outputting them in a single display document for human
> consumption is technically viable. However, this approach raises issues
> in
> terms of information storage (how and where would all the different
> sources be stored), information integrity (how would the integrity of
> all
> the different sources and the output document be secured), and reliance
> on
> applications to correctly associate the appropriate narrative text with
> the
> appropriate data items (how would the human readable document be
> generated
> correctly if applications for associating the narrative text with the
> data
> elements become obsolete or unavailable). Placing the data elements and
> the
> 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
> documents.
> Attached are five "proof of concept" XML instances (two subpoenas, two
> warrants, and a show cause order) marked up using the JXDM. These
> examples
> 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
> schema
> for the document. As I experimented, I went back to modify the subset
> from
> 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
> focus
> on it for the "proof of concept" experiment. I was more concerned with
> the
> narrative text parts of a court document and the JXDM elements
> available for
> marking up narrative text. If you are interested, I can provide the
> document
> schema I came up with.
> To make sure I included appropriate narrative text in the example
> documents,
> I worked from .pdf versions of paper form documents from Maricopa
> County,
> 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
> probably
> to the forms used in Georgia and other states as well. 
> The main thing I discovered is that there are JXDM elements that can
> serve
> as reasonably adequate containers to describe the narrative text in
> form-type court documents such as subpoenas, warrants, etc. This means
> that
> 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 XML
> instance. The data elements can be exchanged and processed by machines,
> and
> the same contents can be displayed or printed for human consumption.
> My
> results are similar in many ways to the sample protective orders that
> Dr.
> Leff and his students created a few months ago. The principal
> difference is
> that those examples place the narrative text inside XML comments, which
> can
> create issues for some XML parsers and for using xslt/xslfo style
> sheets to
> display the information, while I have placed it in JXDM elements.
> One implication is that during the data modeling step in creating an
> IEP,
> someone familiar with the narrative text in various form court
> documents
> should be involved to make sure that narrative text types and elements
> from
> 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
> of
> elements to be changed. Thus the better approach is to structure the
> information in the documents such that the narrative text comes first
> (e.g.
> "YOU ARE HEREBY SUMMONED to appear before this Court to answer the
> Direct
> Complaint at") followed by the appropriate data elements containing
> the
> designated date, time, location, etc. A few times I needed to slightly
> alter
> 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
> material.
> If you want more details, let me know.
> Regards,
> Rolly Chambers
> ---------------------------------------------------------------------
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all your TCs in
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 

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