RE: [legalxml-econtracts] Re: Pruning XHTML2 for eContracts

["John McClure" <jmcclure@hypergrove.com>]

Peter,
I merely expect a continuation of the status quo. It would be a revolution of
current practice for attorneys to directly use a technical software package such
as a DTD driven or XML Schema editor. I think an attorney who hasn't the time to
read our specification for an XML dialect and associated standard practices
wouldn't have the time to learn such a tool in its native incarnation. Tools as
Altova are being customized by after-market, so to speak, software integrators,
to make them palatable to that market segment.

So I share your belief that our core group does not, in the immediate and now,
include attorneys beyond a miniscule number.  If we were to look to such
attorneys for "adoption" of our specification, then we will be making a grave
mistake. I don't think I share your belief that, in the longer run, attorneys
themselves will become fluent in XML or XHTML or, for that matter, in the
intricacies of our specification.

Rather, the core group consists primarily of corporate and independent software
developers -- these are the people who read the specification. They are the ones
who ultimately adopt its guidelines, who decide through market consensus whether
the specification is a success or a failure.

The best strategy I can think of to maximize the probablilty of successful
adoption of our specification --- because, after all, I am not willing to waste
my time on academic exercises --- is to require as little change as possible in
current practices by current practitioners. Current practice is to create HTML
documens, and that will be the case for the next 5 years. This is my fundamental
case for XHTML 2.0: if you want to create a "successful" standard, then do it in
as standard a way as possible.

Current practice by current practitioners is not to worry about validation. We
want to change that for good reasons. We should get people who are or will
publish documents of the type that WE care about --- eContracts --- to publish
them in an XML dialect, not the HTML dialect. That would be a huge win, because
it would expose the documents to XML tools, we'll be able to extract information
from it, we can analyze and manipulate it in a fashion interesting to us, useful
to our customers, and ultimately important to the greater society of humans.
[This is in answer to your question, why even create a standard if attorneys are
not members of the core group? A question you may unfortunately for all of us be
asking of yourself more so than of me.]

With regard to Host v Family, there is a difference from a practitioners view:
it seems an unnecessary complication. Programmers reflexively loathe being told
what to do by architects, designers, and standards organizations --- so let's
not ask more of them than what is clearly necessary, in order for everyone to
win, from the programmers through the attorneys, to the public at large.

Family-level conformance yields non-standard XHTML documents, from the
perspective of one who creates HTML documents. They'll handle easily doing
XHTML --- likely, already doing so --- but they won't take well the idea of
creating documents that are not much more than a knock-off of XHTML, i.e., the
idea of "reusing" a handful of XHTML elements, buried within our own element
structures, would seem relatively risky if not absurd to current practitioners
being asked to change current practice. They will stay with what they know,
HTML, as much they can while they're meeting the "XML game plan" of higher-ups.
This is natural human behavior, and we would do best to work with that, rather
than to fight a battle that won't be won.

Finally, your ask "what proportion of contract documents need to be directly
rendered in a web browser" --- the answer is ALL contract documents, so we
should be attuned to the evolving capabilities of extant browsers. Surely those
browsers will do Host level conforming documents in the shorter run than Family
level.

If Host level confornance doesn't give us all we want, that's fine actually.
Let's publish a Host level module, and then later publish a Family level.
There's no harm in that, and much to be said for it as a reasonable step in the
usual roadmap for standards groups. Take XBRL for instance. Their first spec
standardized only six elements ! With just that, they have established their
credibility, they had a much easier "sell" than if they were to have published
fifty elements, and the DOTr has adopted it for incorporation into their Edgar
standards. Let's walk before we run, by doing a small Host level module.

Regards,
John

Incidentally, you mentioned opposition to our recommending a "Clause" element to
the W3C group. Then you followed by noting that a solution is needed for the
"document parts" problem, which you intend to address yourself when you return.
I proposed the reintroduction of "Clause" as one of three alternatives I see for
handling the "document parts" problem. Of the three alternatives, I think the
"Clause" related alternative is the most likely, though it's not likely that the
W3C group will make any substantive changes at this time.

I know you despise the name, but to me, that's what legal documents are all
about. A "section" element is clearly to me about items that are mentioned in
the <nl> (navigation list) element --- it's a stretch for us to annoint
"section" as perfectly satisfactory as a container of logical paragraphs, i.e.,
<p> elements. I can live with it, but the key attractiveness of XHTML 2.0 is
their change of the semantic for a <p> element, not so much the <section>
element. I agree that a <section> should be allowed to contain logical
paragraphs (and I agree that it should not contain raw text, but that can be
EASILY handled by a "tidy" stylesheet which is the first thing anyone should run
before analyzing further an exchanged datastream). This <clause> element would
bear the same shape (content model) as a section element, with the exception of
course that it not contain <section> child elements (but child <clause> elements
are certainly desired).

I fear that if the W3C does not standardize a <clause> element at this time,
that we may be forced to rely on the "role" attribute on the <section> element
to distinguish between parts of a document, and the clauses within the parts.
It's ugly, but the alternative it appears at this moment would be a Family-level
specification, something I think is premature right now.

Once we publish an XHTML 2.0 based specification, we should focus all our
energies on developing a decent XML dialect that DESCRIBES the content of the
contract. That dialect is used within the RDF document that is linked to the
XHTML 2.0 document --- in no way does it make sense for us to embed such
metadata within the text of the contract. In no way does it make sense to embed
metadata in any <section> of the XHTML document, rather, you write simple RDF
statements such as

<rdf:Description about='http://www.uscontracts.com/contract12345#Sec1234'>
	<idc:title>title of section</dc:title>
	<dc:creator>author of section</dc:creator>
	<dc:date>date authored</dc:date>
</rdf:Description>

The above uses standard Dublin Core elements; we can define our own elements,
packaged and deliverd as the LegalXML namespace, Users can insert into these RDF
datastreams elements from other namespaces such as XBRL, UBL, and many others
getting traction in the world at large. It is our namespace though --- the
LegalXML namespaces --- that deserves our rapt attention and discussion as soon
as we can. The less we are forced to discuss document text markup, the more
significant our contribution will become. I agree that we need a document text
markup strategy, and believe it should be a XHTML 2.0 Host Level compliant
solution as a first step. I find it fantastic that they are going to standardize
the link from the document text to an RDF descriptive document.... let's run
with that.