RE: [legalxml-econtracts] Last comments from me on the prelim SC Report

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

John Messing:
The immediate issue is: what new elements do we need to add to XHTML 2.0 to
achieve our goals? That's basically all we're talking about, as colleagues.

Jason.
I have no doubt that the proposed elements can "work" in an XML editor. And I
agree that we're chartered to support direct text entry of a contract to an XML
editor. The problem is that the justification extended so far for the four
structural elements seems to boil down on the one hand to a matter of
"convenience" for an author and, on the other hand, "DTD validation" to prevent
nonsense combinations of certain attribute values (an issue not nearly as
disturbing to the outside world as you contend) .....

More to your point, because I don't yet understand or because you haven't yet
provided
(1) a business case.... what CANNOT be done in the absence of those four
elements in our standard; and
(2) a technical case.... what is so wretched about using the <div> element for
<extras> and <extra>

then I would therefore vote AGAINST all four of the structural elements
proposed.

With regard to the other elements -- <datearea>, <parties> and <party> -- I
would vote AGAINST all three because they are at a minimum beyond the scope of
work established by the TC for the subcommittee. There are other reasons but to
discuss them is, as you say, "out-of-scope" for the present time.

I don't take extending the XHTML 2.0 dialect lightly. We have good and
compelling reasons for an <instrument> element to identify our document type
within a larger XHTML file; an <nr> element for caption numbers; and <ili> for
inline-lists. Let's be equally as cautious with other extensions to XHTML -- we
need both an airtight business and technical case -- there is no desire to waste
anyone's time jumping through hoops.

John