Re: FW: [legalxml-econtracts] Re: XHTML 2.0

[Jason Harrop <jharrop@speedlegal.com>]

I wrote:

> 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. 


According to http://www.w3.org/MarkUp/xhtml-roadmap/  XHTML 2.0 is intended to 
be a Candidate Rec in Jan 2004 and a Proposed Rec in Oct 2004, but then again, 
that roadmap says "Last Call" in Oct 2003...

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

Grammatical para may not be a key requirement - its yet to be seen - though it 
is a possible solution pattern for us.  Re the recursive container element, yes, 
that's good, though they still have separate list structure - lists inside p, 
and section siblings - with all the issues that raises.

 > It even seems they're
 > 	thinking of dropping the <hx> elements altogether, so I am hopeful that
 > 	no deprecation needs to happen at all.

So when their XML editor asks "what can go here", contract authors will see a 
long list of elements which aren't relevant to contract authoring? eg "code" for 
computer code, <kbd>, <l>, <sample>, <var> etc??

Will one be able to say "i want to use a defined term here", and if so, get a 
popup list of terms defined in the document?  Similarly for cross references?

To enable things such as this, we may need to add our own elements in eg the 
inline module (for this definition example, the proposed "dfn" element gives us 
the definition, but we need something else to "use" (ie IDREF) a definition)

 >
 > 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.
 >

Your response doesn't address the point i was trying to make..

And in any event, those tools are unlikely to be what someone who authors 
contracts everyday for a living will be using.

Current X/HTML editing tools are used by web authors, but not so much by 
contract authors/managers.  They are unlikely to use them as such.  To be 
compelling, the tool must add value, addressing issues such as:

- How will re-use be facilitated?
- How will they add definitions and use them?
etc etc.

They might use Word 2003, or some other tool customised for editing contracts. 
And for these tools, the question is how easy will they be to use, and what 
_characteristics does the underlying grammar have to have_ to make it easy to 
use?  The authors won't care whether its some XHTML variant, or our clause 
model.  But they will care about whether they can do their job easily.

It is clear they could not do their job (adequately) using "strictly conforming" 
XHTML 2.0 in an off the shelf (non-customised) XHTML editing tool.

Whether they could do it using a customised X/HTML language would depend on the 
extent of the customisations to the language, and probably the tool as well.


thanks

Jason


ps more technical stuff below.


Turnning back to the roadmap (and more technical stuff) ...

So far as "Modularization 2.0", all entries are "TBD", but that's 
understandable, since the current draft is already done as a series of modules.

The current draft says at sec 1.2:

	"XHTML 2 is a member of the XHTML Family of markup languages. It is an XHTML 
Host Language as defined in XHTML Modularization. As such, it is made up of a 
set of XHTML Modules that together describe the elements and attributes of the 
language, and their content model. ..

	Over time, it is possible that the modules defined in this specification will 
migrate into the XHTML Modularization specification."

More now on B...

So in any event, we're unlikely to have "strictly conforming" XHTML 2.0 
documents (sec 3.1.1) - since to be that, it looks like you can't add your own 
elements.

We wouldn't be an XHTML (1.0) host Language either, since 
http://www.w3.org/TR/xhtml-modularization/conformance.html#s_conform_document_type 
says we have to keep <kbd>, <l>, <sample>, <var> etc to be that.