It’s 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 –
you’ll 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
doesn’t 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 won’t 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 won’t matter to the person or
the form application -- it’s 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