[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [legalxml-econtracts] Last comments from me on the prelim SC Report
Boy, I don't recall this quote. When was I supposed to have said this? > -------- Original Message -------- > Subject: RE: [legalxml-econtracts] Last comments from me on the prelim > SC Report > From: "John McClure" <jmcclure@hypergrove.com> > Date: Wed, July 21, 2004 8:03 pm > To: "Jason Harrop" <jharrop@speedlegal.com>, "John Messing" > <jmessing@law-on-line.com> > Cc: "Legalxml-Econtracts" <legalxml-econtracts@lists.oasis-open.org> > > 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]