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