Re: [legalxml-sc] FW: White Paper "Tagging Legal XHTML Information" Published

MHonArc v2.5.0b2 -->

legalxml-sc message

[Date Prev]
 | [Thread Prev]
 | [Thread Next]
 | [Date Next]

--

[Date Index]
 | [Thread Index]
 | [List Home]

Subject: Re: [legalxml-sc] FW: White Paper "Tagging Legal XHTML Information" Published

From: "Dallas Powell" <>

To: <>,<>

Date: Fri, 6 May 2005 19:15:14 -0600

I had not heard of this movement.  I wonder if 
we should trademark LegalXML and position ourselves to stop the variations on 
the name if we can.  If we don't others may trademark it and hurt us. 
 As for their position here are my thoughts.

 

It would appear that there is an underlying 
assumption within the LegalXHTML movement that suggests that 
if the proper tools combined with the proper rendering markup for the legal 
industry is created the industry will adopt it.  This assumption then 
mapped as the solution the combination of HTML rendering with XML markup 
specific for the legal industry combined with the use of standard 
XML editing tools. 

 

I disagree.  The challenge is not so much in 
the rendition.  The challenge is in the required skill sets people are 
willing to learn and use to create information. Visual representation 
is very valuable and that is why people use it in word 
processors.    Structured markup is a disaster for the average 
person whether it is easy to render or not.  The challenge is how 
to inject a programming like behavior into the visual and sequential 
creation of information.  Most standard XML tools help the user identify 
which elements are appropriate at each location in the document and insure 
proper syntax conformance.  This however requires familiarity with the 
element names and their dictionary values to successfully apply the proper 
markup.  Most people that create legal instruments are not willing to 
master the dictionary and element names no matter how easy it is to render 
them.  Thus, if one desires create a tool that makes it easy to 
create legal instruments with the proper markup a higher application 
layer beyond the standard XML editors is required.  This higher 
layer of applications must be schema specific.  The problem is that 
each industry ends up with multiple schemas and many variations of each 
schemas.

 

Dallas