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

[John Messing <jmessing@law-on-line.com>]

Agreed except for one final point. What happens if someone decides the
text of a particular part of a  form needs changing and the earlier
category no longer maps correctly to the category of xml text that was
previously assigned to it? How much makework is then involved in making
the changes?



> -------- Original Message --------
> Subject: RE: [courtfiling-doc] Marking up narrative text in court
> documents using the JXDM
> From: "Rolly Chambers" <rlchambers@smithcurrie.com>
> Date: Thu, March 09, 2006 10:21 am
> To: "'John Messing'" <jmessing@law-on-line.com>
> Cc: <courtfiling-doc@lists.oasis-open.org>
> 
>       RE: [courtfiling-doc] Marking up narrative text in court documents using the JXDM        
>  Its true that markup of narrative text goes to the publication/display use more than to the automated processing use. One goal of the Court Document SC was to see whether and how narrative text and data elements might be combined into a single XML instance using the JXDM so that people and machines could consume the contents of a single XML court document instance. My point is simply that it can be done using the JXDM " youll just need to identify the appropriate narrative text elements at the same time you identify the appropriate data elements during the document modeling/IEP stage.   One potential benefit of using semantic tags from the JXDM (e.g. <CourtOrderServiceDescriptionText>) vs. using generic structural tags (e.g. <Text> or <p>) for the narrative text is to avoid the introduction of a generic text element from outside the JXDM. The JXDM doesnt provide any generic structural narrative text elements that I could find among its thousands " it only offers the more semantically descriptive narrative text elements. Also, using the more semantically meaningful tags might make the narrative text components more accessible to machines for further processing " e.g. a smart document assembly application that could copy a particular narrative text component (along with data elements) from one court document and use it to automatically draft another document that a person would ultimately review and finalize. If there is only generic structural markup for all the narrative text in court documents, such an application would not have an easy way to distinguish one generic narrative text component from another.  It also could make finding a particular item narrative text information more efficient and precise if you are looking for that item of information in a collection of XML court documents.   Assuming the user interface for human authors of JXDM court documents is a web form (which makes sense to me) or even an OpenOffice Writer or MS Word form, people wont deal with the particular JXDM elements used in the XML output of the form. The form application would add the JXDM markup and generate the XML instance. Whether the form application places narrative text in a <p> tag or in a <jxdm: CourtOrderServiceDescriptionText> tag wont matter to the person or the form application -- its six of one and a half-dozen of the other. Of course the form processing application will have to be set up to put the correct boilerplate narrative text into the appropriate container element in the XML instance whether that is a jxdm element or a generic placeholder.   Rolly   
>  
>    From: John Messing [mailto:jmessing@law-on-line.com] 
>  Sent: Thursday, March 09, 2006 10:22 AM
>  To: Chambers, Rolly
>  Cc: courtfiling-doc@lists.oasis-open.org
>  Subject: RE: [courtfiling-doc] Marking up narrative text in court documents using the JXDM    
> 
> Rolly:  
> 
> 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 
>  > XML 
>  > 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 
>  > XML 
>  > 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 
>  > IEP 
>  > 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 
>  > OASIS 
>  > at: 
>  > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroupsphp