OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

legalxml-econtracts message

[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]