OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

legalxml-econtracts message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [legalxml-econtracts] XHTML 2.0 issues

Sorry about previous message - I hit "send" too soon.

Comments below.

Rolly Chambers

----- Original Message ----- 
From: "Peter Meyer" <pmeyer@elkera.com.au>
To: "Legalxml-Econtracts TC" <legalxml-econtracts@lists.oasis-open.org>;
"Chambers, Rolly" <rlchambers@smithcurrie.com>
Sent: Tuesday, August 17, 2004 2:17 AM
Subject: RE: [legalxml-econtracts] XHTML 2.0 issues

> 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
> At the most basic level, these containers are needed to simplify the
> authoring process, control automatic numbering and allow the document to
> correctly rendered. They are not intended to detract from any semantic
> information that may also need to be added.

RC: The p and section containers are good components.  Whether putting them
together in one and only one way in a single high level structure will work
best (our current effort) remains to be seen. One alternative is to put
these components together in a few different high level structures a la UBL
1.0 if need be.

> 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
> think it is fully accepted in the TC and is part of the reason why the
> structural markup exercise may have been misunderstood.

RC: Agree. Some of the problem is that for certain contract documents (e.g.
some consumer agreements) certain information such as warranty disclaimers
must be displayed in a particular way to be legally enforceable. These
situations are directly at odds with separating content from display. Some
consideration about how these situations will be covered by an eContracts
schema is justified, but need not become the primary focus of our effort.

> 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
> NEED to use XML to make contents more machine readable. My point was that
> need to find out the real requirements for a standard. I make no
> about the end result.

RC: I should be the one to apologize for misunderstanding. Perhaps our
accents got in the way.

> 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
> assumption that the requirements process could be conducted in parallel
> it. Clearly that assumption was wrong.

RC: I thought it was a reasonable proposal at the time and still do. It
hasn't played out quite the way we were hoping, but it was still a good

> 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
> 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
> that it may not be true with other use cases.

RC: If the semantic markup affects and will benefit eContracts, then I'd say
it's in scope even if it also may apply to other legal and business
documents. No doubt there are semantic markup needs that apply to documents
other than contracts. Some day there may be a way to fuse them together.
However, I don't think this limits the way we can approach using semantic
markup with eContracts. I'm not understanding why you see this as a scope

If your point is that there are already too many flavors of XML "price,"
"party," and "payment" elements to choose from so adding one more is
pointless, then I disagree. I'm not in favor of trying to re-write UBL or
any other XML business vocabulary, but I'm not bothered if there is some

> Another problem I have is a perception that some people want a standard to
> enc0
ompass 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
> standards, particularly new standards should try to achieve.

RC: I want the simplest set of eContracts semantic markup possible to start
with so the standard has room to evolve. I am not interested in embedding
anyone's particular business model in the standard.

> 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
> 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
> > make it easy for authors, easier for application developers and useful
> > 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
> > 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
> > 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
> > 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
> > the div element or inventing new elements. There is disagreement about
> > 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)
> >
> > 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,
> > XML markup can be rendered on the web using style sheets. The use of
> > 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
> > we should stay within its constraints.
> >
> >
> > 4. Conclusions
> > 4.1  The critical issue is that the schema we adopt or develop should
> > 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
> OASIS TC), go to
> ve_workgroup.php.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]