Re: XHTML 2.0

[Jason Harrop <jharrop@speedlegal.com>]

Hi John

What i'd suggest is that you allow the TC to decide over the next 2-3 weeks 
whether it prefers a simple/typographical para model or a grammatical para model.

Then, if you want to put something based on the XHTML 2.0 draft on the table as 
an alternative to whichever of those two we're favouring, by all means do so.

To be able to properly evaluate XHTML 2.0, which prudence and good sense 
suggests we would *have* to do to before we commit to walking down that road, 
there are five things which spring to mind:

A.  When will it be ready?  How final is it?  Maybe Dan or Dave can get some 
visibility on this from the non-public W3C mailing lists. This goes to your claim 3.

B.  What does the subset you are proposing actually look like?  What elements 
are in it?  ie what is the concrete proposal, expressed as a schema (W3c, relax 
or dtd)

C.  How does it compare to our other candidate for a range of authoring and 
other tasks, which we can list and then answer.  ie we need to be comfortable 
that your claim one - that it is adequate - is fair.

D.  Looking down the rest of the structural path from basic clause model -> 
fleshed out clause model -> complete contract, where is the effort involved? ie 
how much time will XHTML 2.0 actually save us?  i think a significant part of 
the remaining effort will be common to both XHTML and custom models, since it 
lies in signature blocks etc, and not so much in the fleshing out part eg span, 
metadata, table model, images.

E.  Will XHTML 2.0 be the market behemoth several of us are assuming?  Will it 
sweep all before it, so that no other XML grammars are used for document 
authoring anymore?  If so, why didn't XHTML 1.0 have the same effect.

Much as I'm interested in moving on to the non-structural stuff, we need to be 
able to mark up structure before we can sensibly talk about the other stuff ie 
you've got to walk before you can run.

Two final points - (i) how long this all takes is dependent in large measure on 
having a suitable process. (ii) And if people don't want to discuss the clause 
model in our regular teleconf, we could schedule a separate one (perhaps for a 
sub-committee) and do it there. Frankly, there shouldn't need to be a 'long 
series of calls' though. And as Dave observed, some of the complexity we are 
dealing with can be seen as belonging to structure, or some other level. So 
bifurcating will probably make things like metadata harder to handle.

cheers,

Jason



> Subject: XHTML 2.0
> 
>     * From: "John McClure" <jmcclure@hypergrove.com>
>     * To: "Legalxml-Econtracts" <legalxml-econtracts@lists.oasis-open.org>
>     * Date: Wed, 19 Nov 2003 21:01:20 -0800
> 
> Folks,
> This starts a thread for discussion about using XHTML 2.0 as our clause model.
> My claim is:
> 
> 1. Its clause model matches our requirements *adequately*, despite any fluff
> it's said to have.
> 2. We best standardize Modular XHTML modules for signature blocks & other items
> as needed
> 3. XHTML 2.0 will be standardized well-before signficant audiences even read our
> documents.
> 
> The primary disadvantage of rolling our own to me is that it distracts us from
> marking up the information *in* the contract, a task that I know several of us
> would like finally to 'get on with'. Whatever you want to call them, legal
> obligations or simple events, these are the things that deserve our precious
> time. Today's call was certainly testimony to our ability to work together,
> however I must conclude after three (?) consecutive calls devoted to the "clause
> model", after quite a few previous related skirmishes, that this is but the
> beginning of a long series of calls about the design of elegant markup for
> 
> 	1. tables of contents, though XHTML 2,0 provides a perfectly adequate
> 	set of "navigation list" elements for this job.
> 
> 	2. tables, though the HTML table model is used in 99% of markup today.
> 
> 	3. inline elements , though XHTML has a complete set of useful, known,
> 	presentation- and linking-related inline elements. We can even discuss
> 	how a <cite> element is to be written to content within an XHTML 2.0
> 	contract.
> 
> 	4. metadata elements, though XHTML very adequately provides for this,
> 	even now moving to standardize a pointer to RDF metadata about the
> 	XHTML	2.0 document. This addresses our metadata needs well enough.
> 	Additionally, the 2.0 draft also explicitly addresses incorporating Dublin
> 	Core elements, so document indexing metadata requirements are now
> 	met.
> 
> 	5. list elements, which apparently are inadequate in XHTML 2.0. But
> 	there is nothing stopping us from identifying changes to the current
> 	W3C draft, at the same time that we express our need for a numbering
> 	element used only within their new <head> element.
> 
> Given all this, I shudder at spending many more months of phone calls working
> out solutions for problems that are already solved by XHTML 2.0. I truly believe
> that the focus of our energy should be on developing the metadata about the
> language of the contract  -- it's now clear that the industry accepts storing
> metadata in an RDF file, so let's be decisive about our direction for the coming
> year.
> 
> Let's define a few XHTML modules (a Signature Module and an Attachments Module
> at least) and several RDF datastreams (one for each event in the "life" of a
> contract). Let's standardize 'best practices' on the use of XHTML. Let's create
> a standard that is as relevant as possible to the real world happening all
> around us.
> 
> Basically, I'd like to have a vote soonest on whether the Clause Model
> discussions can now be suspended indefinitely, and we now investigate creating
> Signature and Attachment Modules for use by XHTML 2.0 datastreams. I think such
> work would considerably improve the Requirements document.
> 
> Thanks,
> John
> 
>