Re: [legalxml-econtracts] Last comments from me on the prelim SCReport

[Jason Harrop <jharrop@speedlegal.com>]

I fully expect you to vote against the proposal.  No drama there.

What i am finding infuriating is that you are complaining about it, 
without publicly putting up an alternative.

You hinted that producing your alternative depends on whether the TC 
finds the authoring use case compelling, but when pressed on this point, 
still won't put up your alternative, or withdraw.

I personally have a pretty good idea of what your alternative looks like 
(nested divs, <area>, out-of-band RDF), and the problems it brings with 
it, but until you put it before the TC, there is nothing concrete to 
comment on.

When you put it forward, it will become apparent that it is not suitable 
for authoring.

One way forward (once it is on the table) may be to have an authoring 
DTD (using my/Peter model), and a separate 'publishing' DTD (call it 
what you will - but i guess it would be XHTML 2 + John's <area> element, 
plus possibly related RDF files).

Authors would author with the authoring DTD.  That XML could be 
transformed to the publishing DTD, for anyone who wished to do so, or 
for that matter, to XHTML2, PDF, RTF etc.

However, until we get past structural and start to talk about how any of 
the possible structural alternatives (eContracts structural, WordML, 
XHTML or whatever) are tied to the semantic layer (vertical industry 
dialects), its not clear what that publishing DTD should look like, or 
how useful it would be.

cheers,

Jason

ps <datearea> and <parties> are not out of scope.  Only appendix 3 is 
(that is, how you might markup the stuff inside a party paragraph). 
<datearea> and <parties> are critical for UK/ANZ users, but, as i have 
been at pains to point out, unnecessary for USA users.




John McClure wrote:
> 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
> 
>