FW: [legalxml-econtracts] Re: XHTML 2.0

["John McClure" <jmcclure@hypergrove.com>]

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)

	I favor deprecating, not removing, elements from whatever schema
	the W3C issues for XHTML 2.0. It seems to me that the W3C committee
	is (a) doing the right things so far and (b) open to change. It's a good
	sign to me that they've create a grammatical paragraph and a recursive
	container element, meeting two key requirements. It even seems they're
	thinking of dropping the <hx> elements altogether, so I am hopeful that
	no deprecation needs to happen at all.

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.

	There is every reason to believe that current X/HTML editing tools,
	both free and proprietary, will be updated for 2.0.

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.

	It's not just how much time is involved with haggling over design for
	something that we do not need, for something that is met by a more
	widely-extant standard. I wonder whether trying to standardize an
	industry-specific paragraph model is a good use of our time in the
	face of a "good-enough" standard for a paragraph model that is going
	to be instantly recognized by all major stakeholders we care about.

	I agree that we need a Signature Module. I also believe we need to
	develop an Attachment Module and (new) an Instrument Module.
	I am calling to begin work on these immediately. I see zero gained
	by having any more calls devoted to our own paragraph model.

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.

	Well, you wrote a good analysis of the inadequacies of XHTML 1.0.
	These are being fixed in XHTML 2.0, so we now should adjust our
	direction and priorities.

	No other viable grammers for document authoring? As a matter of
	** standardized document exchange among arms-length parties **
	tell me what's the point of a standard that has a different direction
	than that prevalent in the greater industry? Sure, MS Word can have
	its own, but you can be sure that it will read XHTML 2.0 documents !!!!
	You can be sure that MS will update its IE software for 2.0 docs!

	The Open Office dialect, if it's going to get any traction, must first be
	supported by the Mozilla platform. However you know that Mozilla is
	itself focused on implementing W3C standards (faster and better than
	MS incidentally) so it's going to be implementing XHTML 2.0 support
	you can be sure well before Open Office.

	It's up to the parties if they agree on using Open Office or DocBook
	dialects. They'll probably need to use XSL stylesheets to generate
	either XHTML or SVG that is displayed by the browser. It's those XSL
	output streams that are significant and central to any standard for
	representing a contract recorded on a digital medium, marked up using
	the XML.

	The only big issue in my mind is whether any CSS-using, non-XSL using,
	XML dialect conforms to our standard, and the answer can be yes only
	if we require that metadata must accompany the XML+CSS file, and that
	metadata conforms to our requirements. We state that the metadata
	must contain a map of the structure of the document, but such is only
	needed when it is something other than an XHTML 2.0 document.

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.

	Agreed. XHTML 2.0 provides all the structure we require. So now let's
	talk about the other stuff.

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.

	I'd like to see the metadata placed into an RDF entity separate from
	the "structural content" so I don't see why we can't split the group if
	that's really what's necessary. For my part, I'd likely take a lengthy
	sabbatical if the group wants to continue with its own clause model.