XHTML 2.0 issues

["Peter Meyer" <pmeyer@elkera.com.au>]

Hi folks,

Some points on XHTML 2.0, as discussed at the last meeting.

1. Background, why we chose XHTML 2
1.1 Some of us could not agree on a completely new structural markup model.

1.2 XHTML 2 introduces a structural model into HTML using recursive section
containers and p containers.

1.3 This motivated some of us to think that it would provide a close enough
starting point for contract markup.

1.4 XHTML 2 seemed attractive because it is XHTML and would be an easier
sell to developers than an entirely new schema.

1.5 It was perceived as an advantage of XHTML 2 that it would make it easier
to transform eContracts for web publishing.

1.6 Some of us believed (and still believe) that straight XHTML 2 markup was
too loose to be useful and that we must strip it down to a simple model to
make it easy for authors, easier for application developers and useful for
content management and document production.

1.7 For my part, I promoted XHTML 2 on the basis that it should give us a
markup model based on one that would become fairly familiar in the
marketplace over the next few years, that we could shape to our needs and
that this would give us a marketing advantage we would not enjoy with an
entirely new schema. In summary, the advantages of XHTML 2.0 for me were
more marketing than technical.


2. What we have learned
2.1 A strict version of the section and p markup is capable of meeting our
clause model needs, although its not perfect. For example:
 (a) HTML lists are not suited to real documents that require flexible
numbering schemes
 (b) Some aspects are not well thought out, such a the l element.
At this level we could use something that is a subset of XHTML 2.0. An
eContracts schema could not accept most XHTML 2 markup but it would be easy
to go the other way.

2.2 XHTML 2 does not have an obvious way of providing the high level
structure found in contracts. We are faced with either using (over using)
the div element or inventing new elements. There is disagreement about how
many are needed and the design approach required.

2.3 Some new inventions are essential, including signature blocks but there
are differences about how to design markup for these.

2.4 There seem to be some strong differences within the TC about the meaning
of generic structural markup, the need to support human authoring of
contracts using XML editors and the role of XML in "the contract".

2.5 There seems to be some support for implementation of our own namespace.


3. What do we need from XHTML 2?
3.1 Do we need strict conformance to XHTML 2? I suggest this is not
particularly important. Its an unnecessary straight jacket and we should use
it only while its convenient. Most of the benefits will flow if we can keep
to the section and p markup that has some prospect of becoming familiar to a
fairly wide community, particularly if other legal and business document
markup standards use a similar schema.

3.2 Do we need XHTML 2 to publish eContracts on the web? Increasingly, any
XML markup can be rendered on the web using style sheets. The use of XHTML
markup may make this a bit easier but in the vast majority of contract
documents this may not be very important.

3.3 It is not clear what else we really need from XHTML 2.0 or how closely
we should stay within its constraints.


4. Conclusions
4.1  The critical issue is that the schema we adopt or develop should meet
the needs of the proposed standard. At this stage, these needs are
insufficiently defined for us to be able to resolve the issues, such as
those mentioned in 2.4 above, that have been with us since formation of the
TC and for years before in the old Legal XML.

4.2 Until we complete the requirements process we will not be able to
resolve the outstanding issues about the use of XHTML 2.


regards
Peter Meyer