[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]