RE: [legalxml-econtracts] XHTML 2.0 issues

["Chambers, Rolly" <rlchambers@smithcurrie.com>]

My comments are below.

This is a helpful explanation of the thinking behind the recent structural markup proposal.

Rolly Chambers

-----Original Message-----
From:	Peter Meyer [mailto:pmeyer@elkera.com.au]
Sent:	Mon 8/16/2004 10:13 AM
To:	Legalxml-Econtracts TC
Cc:	
Subject:	[legalxml-econtracts] XHTML 2.0 issues
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.

[RLC - could be but I think ease (or difficulty depending on your perspective) of transforming eContracts for web and other publishing will be comparable whether XHTML2 or some other XML dialect is used.]

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.

[RLC - Agree heartily with simplifying straight XHTML 2 and approve of the effort to date. I'd encourage the subcommittee to try simplifying further if there is any consensus to do so.]

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.

[RLC - agree.]

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.

[RLC - the "other way" being that an XHTML 2 schema/dtd would accept eContracts markup?] 

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.

[RLC - UBL appears to use a different design approach. UBL 1.0 provides "a library of XML schemas for reusable data components" and "a small set of XML schemas for common business documents such as 'Order,' 'Despatch Advice,' and 'Invoice' that are constructed from the UBL library components . . . ." "The UBL library is designed to support the construction of a wide variety of document types beyond those provided in the 1.0 package . . . ."  

In effect, the components in the UBL "library" (which have semantic names but are components in the same way as our proposed section and p elements) are not pulled together into the single, high level "one structure fits all document types" manner that we are exploring. Instead, the UBL components are combined in different ways to assemble eight different document types.

I am not advocating a UBL-type design approach -- just observing that it is an alternative. If followed, this approach would allow sections and paragraphs to be assembled in varying ways. Section and p could be assembled in one way to offer structure for lengthy formal contract documents of the type Jason has cited examples of. These same components also could be assembled in a different way for more informal types of contract (and other) documents.]

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

[RLC - agree that eContracts will need a place for information customarily found in paper "signature blocks." This is not the same as digital signature info in my mind.]

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

[RLC - agree there are differences about what constitutes "structural" markup.  In a sense, even "structural" markup elements are semantic -- it's just that their semantics are generic and don't describe the information they contain in a particularly meaningful way.]

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

[RLC - agree we should define an eContracts 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.

[RLC - the ease or hassle of using stylesheets or scripts to publish XML documents looks unavoidable to me. It's the result of assuming that "separation of content from display" is a good thing.]

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.

[RLC - This may be assuming that there is a need to use XML only to publish large contract documents (a need served by "structural" markup), but no need to use XML to make the contents of contract documents more machine readable to facilitate the exchange of contract data with other systems for purposes besides publishing (needs served better by "semantic" markup).