legalxml-sc — archive

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

From: Dallas Powell
To: [email protected]
Date: Sat, 07 May 2005 01:16:00 -0000

MHonArc v2.5.0b2 -->

legalxml-sc message

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

From: "Dallas Powell" <[email protected]>
To: <[email protected]>,<[email protected]>
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