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


Sorry for the confusion.

And for becoming longwinded in this posting, perhaps.

My take on the problem that you have posed is between machine storage
methods and human usage, which builds upon the distinction you have
been consistently stating between data- and document-centric approaches
to mark-up. At the current level of technology, machine processing
consists largely of storing and retrieving meta data in database fields
and documents in a document storage system that may consist of file
directories with database pointers to the files or within the database
itself.

XML documents consist largely of structures that are consistent with the
database storage structures. Hence the data-centric term.

Human documents are designed for human reflection and action based upon
a system of language, culture, customs and societal functions. One-off
documents like those generated by lawyers as pleadings in complicated
cases have structure, but it cannot be rendered easily into machine
readable structures with today's technology because such technology is
not able to meaningfully capture and render the related language,
culture, customs and societal functions.

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.


> -------- 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 11:11 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   
>  Changes to what " the input form, the form processing application, the xslt style sheet for displaying/publishing the XML instance, or the older (and now incorrect) XML instances?   It should be easy to change an xslt style sheet so that the output of the new element and its contents will be the same as the older one. Revising the form and form processing application could be more complicated but Id think you would just substitute the new jxdm: element and text for the older one. Changing the older (and now incorrect) XML instances could be done easily with an xslt style sheet " in effect the style sheet would be generating an improved version 2 of the original XML document.   Im probably missing something here. 
>  
>    From: John Messing [mailto:jmessing@law-on-line.com] 
>  Sent: Thursday, March 09, 2006 12:07 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    
> 
> 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?  
> 
>



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