Re: [legalxml-econtracts] XHTML 2.0 issues

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

Good to hear something back. My brief follow up is inline below.

Thanks.

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