RE: [legalxml-econtracts] XHTML 2.0 issues

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

Hi Rolly,

Thanks for the comments. I make some observations on three points you
raised:

2.2 - UBL
I'm no expert on UBL but I don't think this addresses the basic need to
define high level structure of a contract for purposes of structural markup.
At the most basic level, these containers are needed to simplify the
authoring process, control automatic numbering and allow the document to be
correctly rendered. They are not intended to detract from any semantic
information that may also need to be added.

3.2 - separation of content and display
Yes, the whole point of the structural markup is to separate content from
display. Going forward, I think we will need to establish whether this is
what we want to achieve as part of our requirements process because I don't
think it is fully accepted in the TC and is part of the reason why the
structural markup exercise may have been misunderstood.

4.1 - structure & semantic
Rolly says:
> [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).

In connection with what I said in point 4.1, I think you have completely
misunderstood what I said. I apologise that my point seems to have been so
unclear. I have never assumed or advocated that XML is needed ONLY to
publish large contract documents. Nor have I ever asserted that there is NO
NEED to use XML to make contents more machine readable. My point was that we
need to find out the real requirements for a standard. I make no assumptions
about the end result.

The structural markup initiative was designed to deal with the publishing
stuff first and to provide a common platform on to which semantic markup
could be added, by those who need it.
We started this way because I do not believe it is possible (at least
practicable) to do it the other way.
For what its worth, I believe that the semantic layer should be capable of
being added to any schema, not just the structural schema we develop.

In retrospect, the proposal to move on the structural markup without
comprehensive requirements may have been a bad idea. It was proposed on the
assumption that the requirements process could be conducted in parallel with
it. Clearly that assumption was wrong.

I remain very confused about the needs for semantic markup in a proposed
eContracts standard.

Many of the possible semantic markup needs seem to me to apply to a wide
range of legal & business documents. If so, they may be beyond the scope of
this TC. That is certainly the case with the most of the semantic markup
needs that emerge from the negotiated contracts scenario I posted. I accept
that it may not be true with other use cases.

Another problem I have is a perception that some people want a standard to
encompass every aspect of a very specific transaction model they have in
mind. Its almost as if they want to embed their business model in the
standard. I believe a standard must avoid this. The standard should allow
people to work the way they want to work and allow technologies and
processes to evolve. It should define only those processes that are
necessary to support a widespread business need. If we try to reflect very
specific transaction models, how many models must be supported and at what
complexity in the standard? That approach seems to be inconsistent with what
standards, particularly new standards should try to achieve.

These problems are not insurmountable. We just have to start at the
beginning and work out what we are trying to achieve. In that process we
should be able to work out the common needs of a wide range of user groups
and develop a standard to meet those needs first. Having had a quick read of
your use case, I am fairly sure this process will allow us to achieve this
goal. It will take some work and we will each need to be open to review of
what we think are our requirements.

Regards
Peter








> -----Original Message-----
> From: Chambers, Rolly [mailto:rlchambers@smithcurrie.com]
> Sent: Tuesday, 17 August 2004 1:56 PM
> To: pmeyer@elkera.com.au; Legalxml-Econtracts TC
> Subject: RE: [legalxml-econtracts] XHTML 2.0 issues
>
>
> 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).
>
> From my perspective, TC members are interested in more clearly
> defining both needs and have agreed to have a go at the
> "structural" markup first. However, that does not imply a lack of
> interest in or need for "semantic" markup.]
>
> 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
>
>
>
>
> To unsubscribe from this mailing list (and be removed from the
> roster of the OASIS TC), go to
> http://www.oasis-open.org/apps/org/workgroup/legalxml-econtracts/m
embers/leave_workgroup.php.


To unsubscribe from this mailing list (and be removed from the roster of the
OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/legalxml-econtracts/members/lea
ve_workgroup.php.