RE: [legalxml-econtracts] XHTML 2.0 issues

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

Thanks Rolly, your points are all well taken.

regards
Peter


> -----Original Message-----
> From: Rolly Chambers [mailto:rlchambers@smithcurrie.com]
> Sent: Wednesday, 18 August 2004 6:45 AM
> To: pmeyer@elkera.com.au; Legalxml-Econtracts TC
> 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
> 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.
> >
>
> 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
> 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.
> >
>
> 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
> 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.
>
> 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
> the
> > assumption that the requirements process could be conducted in parallel
> with
> > 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
> shot.
>
> > 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.
> >
>
> 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
> issue.
>
> 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
> overlap.
>
> > 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
> what
> > 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
> 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.
> >
>
> RC:
>
> > 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/m
embers/lea
> ve_workgroup.php.
>
>