[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [legalxml-econtracts] Thinking about the Scenarios
Hi everyone Here are some thoughts in progress about the scenarios, intended in advance of next week's teleconf to stimulate discussion as to where we go from here. The following seven scenarios have now been posted to the list: - Automated Negotiation System http://lists.oasis-open.org/archives/legalxml-econtracts/200302/msg00016.html - Click-Through Contracts for Software Downloads http://lists.oasis-open.org/archives/legalxml-econtracts/200302/msg00012.html - Contract Generation Systems http://lists.oasis-open.org/archives/legalxml-econtracts/200302/msg00014.html - Data Consortium Contract Schema Requirements http://lists.oasis-open.org/archives/legalxml-econtracts/200302/msg00006.html - Dispute Resolution and Litigation Involving Contracts http://lists.oasis-open.org/archives/legalxml-econtracts/200302/msg00013.html - Enterprise Contract Management http://lists.oasis-open.org/archives/legalxml-econtracts/200302/msg00007.html - Law Firm Contract Creation and Negotiation http://lists.oasis-open.org/archives/legalxml-econtracts/200301/msg00003.html These scenarios all have something in common, but also significant differences. Allow me to summarise (for all except the Data Consortium): - The "Law Firm Contract Creation and Negotiation Scenario" wants to represent existing formal legal contracts in XML, so that XML-aware authoring tools (eg Word 11, or Altova's now free Authentic editor) can be easily used by lawyers to draft them, and the resulting document can be formatted, printed and signed. - That scenario also suggests certain things be marked up (see 114) for use in downstream systems. - The "Contract Generation Systems" scenario directs itself to creating a contract from a space of possible contracts. - The "Automated Negotiation Scenario" seems to require that there be "slots" or elements in an XML contract, into which the parameterised business terms can be placed. - The "Dispute Resolution and Litigation Involving Contracts Scenario" requires obligations and "conditional clauses" to be marked up in very specific ways. - The "Enterprise Contract Management" scenario may require more or less markup than the "Dispute Resolution" scenario [Barry?] - That "Dispute Resolution" scenario also posits an exception mechanism, which mentions a "contract drafting system", which seems a much grander vision that the drafting systems spoken of in the "Law Firm Contract Creation" and "Contract Generation Scenarios". - The "Click-Through Contracts for Software Downloads" Scenario is relatively straightforward, except for the question of whether it is desirable to represent these using the same document model as might be used for the "Law Firm Contract Creation" scenario. I'd like to suggest our work divides in to two (possibly three) parts: 1. A representation of the contract in XML, in a way which allows it to be rendered in various output formats. This seems to be more or less required by each of the scenarios. The open questions here are firstly, what subset or subsets of the universe of contracts should we be seeking to represent, and then, our real work: what representation to use (eg nested/flat, recursive etc) 2. Markup of some or all of the information which is contained in (or could be inserted in) clauses in the contract. Most of the scenarios require this, but vary significantly in what to markup, and for what purpose. The last teleconference suggested a possible third part: 3. Information _about_ the state of the contract (or a part of it), for example, whether the contract has been signed, whether a particular clause has been agreed, whether a clause has been breached. The distinction between 2 and 3 is fuzzy around the edges. We need to decide at some point what to do with information of type 3 (which i'll call metainformation). Do we add markup to the contract to cover some/all of it, or do we agree it will be kept outside the marked up contract, to possibly later become the subject of further standards work. It seems to me that a useful way forward would be for us to concentrate on (1) above as soon as our requirements exercise is complete. If we could do this, we'd have created something we can usefully start to work with, and importantly, have a springboard for (2), since we'd be able to post XML fragments to the list using an agreed structural/skeletal markup, and concentrate fully on identifying the info we were marking up and the proposal for marking it up. I think it would be useful for the scenario authors to refactor (and perhaps add to) their scenarios, so that their requirements are categorised: 1. Skeletal/Structural, for formatting and other purposes 2. Markup of particular information: (a) at the clause level (b) inside a clause 3. Meta information 4. OTHER cheers, Jason -- Jason Harrop CTO, SPEEDLEGAL jharrop@speedlegal.com Melbourne Mob +61 (0)402 02 66 34 Tel +61 (0)3 9670 0141 Fax +61 (0)3 9670 0142 www.speedlegal.com SmartPrecedent(R) software The most intelligent way to create documents ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]