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] eContracts TIME CHANGE ALERT and AgendaClarification


Hi John

In the interests of brevity and clarity for people reading this before the call, 
I'm only replying to one or two aspects of this note.

You wrote:
> As our first priority, I suggest that XML-encoded evidentiary contracts should
> be treated as comprehensively as possible, particularly when we *know* that many
> parties will be happy to encode their contracts in XHTML or SVG, whether
> natively or by action of an XSL-T stylesheet against their own XML dialect, or
> MS XML, or Docbook, or an XForm, or an XSL-FO (or even voice) .

> I frankly don't
> grasp why the H/M dialect should be our highest priority in the face of the far
> more likely prospect of the industry generating pretty standard presentation
> datastreams.

Yes, the industry will generate "pretty standard presentation datastreams". In 
fact, very standard ones - not just XHTML, but also non-XML ones.

They could do that as you say, from their "own XML dialect, or MS XML, or 
Docbook, or an XForm, or an XSL-FO"

But presentation datastreams are just one of the things people expect to be able 
to get from our standard.  They are a given.  The only question is how much (if 
any) we need to say about them. (Quite possibly not much)

Many of the potential benefits of our work rely on _an appropriate XML dialect_. 
  This is not MS XML, or Docbook, or XSL-FO, or some XHTML based language.

It is an XML dialect which is designed specifically to represent a contract. 
The advantages of such a dialect will make it _compelling_ for:

- authoring/editing contracts in XML
- storing precedent contracts
- negotiating contracts using XML
- managing contracts in an XML-based contract management system
etc

You don't have to use it.  But you are free to.  And if you do, you can generate 
your standard presentation datastreams, and do whatever you like in that world.

The disadvantage of not having a specialised XML dialect is that the critical 
mass we are expecting will never eventuate.  I say "never eventuate" because few 
people (far fewer) will use the XHTML based language you are advocating.  XHTML 
is a square peg in a round hole.  It contains a large number of elements 
ill-suited to contract drafting, and would need to be augmented by others which 
are missing if it is going to suit contract structures.

Its not a matter of having "the self-restraint to keep away from document 
authoring".  Quite the contrary. I think document authoring - making it easy - 
must be one of our primary considerations.

If people can't author eContracts, how are they going to happen?

(Not in a word processor, then "save as xhtml..", because that won't give you 
anything except plain XHTML...)

Creating a clause model doesn't have to be the TC's "highest priority" or "the 
emphasis" of the specification. But it is an important part, a part which can be 
advanced with the input of interested members, and an outcome which the TC can 
regard as a useful contribution to the world at large.




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