[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Req Doc Review, Updated Tech Reqs, & 3 pictures
Attached is an update to my previous draft for a Technical Requirements section, with no plan to further update until after receiving feedback on its direction. I have also attached a few inline-comments to the Requirements Document. As I'm certain it was an oversight, the link to the DC requirements was to only its first draft. Accordingly, I am concerned that that first draft was used as the basis for the Reqs Doc, rather than that posted 10 days later (http://www.oasis-open.org/archives/legalxml-econtracts/200302/msg00009.html). Lastly attached are graphical depictions that I was requested to furnish relative to those requirements, refined beyond the concepts originally presented. Thirty-seven types of events are now identified. Comments about all this material is welcomed.Title: LegalXML eContracts XML Markup Requirements
Working Draft 01, 2003-10-31
Copyright (c) 2003 OASIS Open, Inc. All Rights Reserved. Table of ContentsAppendixesThis document describes the basic functional requirements for a standard XML syntax for the markup of electronic contract documents. The charter of the OASIS LegalXML eContracts TC provides that such a standard for XML markup should enable "the efficient creation, maintenance, management, exchange, and publication of contract documents and contract terms." The requirements described in this document are the result of a process undertaken by the eContracts TC to define in more detail the requirements for a standard "contract documents" XML syntax based on the broad scope outlined in the TC's charter. The process included a basic review of other XML markup standardization efforts that might be useful in establishing standard XML markup for electronic contracts, but it primarily involved the creation and review of written scenarios by TC members. The scenarios presented problems to be addressed and needs to be met in specific business contexts. The general requirements described in this document are derived from the submitted scenarios. The description of XML markup requirements, like the description of software requirements, can be approached from several different perspectives and involves a range of considerations. Functional, technical, system, business, and other factors are important considerations. This requirements document focuses on describing from the perspective of users the basic functional requirements to be met by a standard eContracts XML syntax. The requirements are derived from and traceable to the scenarios submitted to the eContracts TC, and identification of additional requirements for XML markup of electronic contract documents is expected and welcome. This document does not attempt to define detailed technical or system requirements for XML electronic contracts nor does it attempt to define requirements for software applications that might be used to create or process XML electronic contracts. I suggest the reader can't yet answer:
The key words must , must not , required , shall , shall not , should , should not , recommended , may , and optional in this document are to be interpreted as described in rfc2119. The term author means a person creating or editing an XML contract document. The term contract document means a draft or final electronic document formally expressing and memorializing the legally enforceable promises, understandings, obligations, and mutual assent of two or more contracting parties. Formal contract documents are a broad category of documents that include real estate leases, construction contracts, licensing agreements, loan agreements, merger agreements, employment contracts, contracts for the sale of goods, trading partner agreements, and similar documents ordinarily involving commercial transactions. Within this requirements document, contract document does NOT mean letters, email, memoranda, notes, or similar informal documents (although even such informal documents could constitute legally enforceable written contracts in some circumstances). The term contract term means a business term within a contract document such as a price, payment, quantity, scope description, quality description, schedule, date, or similar business term concerning the subject of the contract. The term developer means a person creating or developing software for processing XML contract documents. The terms processing application and application mean software applications for processing XML contract documents. The term user means an author, developer, manager, or reader using an XML contract document.
The anticipated users of a standard eContracts XML syntax include:
Contract document creators include persons responsible for preparing contract documents for an organization. Contract document creators may be employees, attorneys or law firms, or consultants or consulting firms. They may work from document templates or form contracts in drafting final contract documents. Contract document creators presumably will have at least basic familiarity with and may have special expertise regarding the business processes, contract terms, business semantics, contract drafting principles, and contract administration practices within their business sector. They presumably will have little, if any, familiarity with XML markup. XML applications developers include employees or consultants familiar with developing software applications for creating, exchanging, or processing XML documents or data. Applications developers presumably will be familiar with XML based standards and with programming languages used for creating XML processing applications. They may or may not be familiar with business processes, contract terms, business semantics, contract drafting, or contract administration practices within a business sector. Contract administrators and managers include employees or other persons who read, review, catalog, administer, or execute contract documents. This group includes individual consumers. Contract administrators, managers, or consumers presumably will have little, if any, familiarity with XML markup, but presumably will have at least basic familiarity or even special expertise regarding applicable business processes, contract terms, business semantics, and contract administration practices within their business sector. Automated contract negotiation applications include specialized software "agents" capable of negotiating and forming contracts. Automated contract negotiation applications will have the capability to exchange contract terms marked up in XML and to generate XML contract documents memorializing the outcome of an automated negotiation process. Processing applications include software programs capable of automatically recognizing and extracting pertinent contract terms marked up in XML, and further processing or exchanging such data and information with other applications, such as data bases or applications for displaying or rendering information marked up in XML. Contract documents are created, exchanged, and administered in many different business contexts. Relevant business sectors include, but are not limited to, real estate, banking and insurance, construction, securities, government and private procurement of goods and services, software licensing, and many more. The semantic business vocabularies used within different vertical business sectors are extensive and vary substantially from one sector to another. Many of these semantic business vocabularies are or can be expressed as standard XML dialects. A standard XML syntax for electronic contract documents must accomodate a multitude of contract terms and business semantics, including XML elements and attributes from other XML dialects, in order to enable the efficient creation, exchange, and management of contract documents and contract terms within different vertical business sectors. Although semantic business vocabularies vary across vertical business sectors as a general matter, there appear to be common core semantic contract terms that apply broadly to contracts in many different business contexts. These common semantic contract terms include such terms as "price," "obligation," "contract party," "payment," "quantity," and similar contract terms. Obligations expressed within contract documents may be conditioned upon the occurrence of a variety of events external to the contract, such as the passage of a specific time duration, the existence and discovery of defects, or the failure of a contracting party to perform its promises. Where core semantic contract terms can be identified, a standard XML syntax for contract documents should include them and should provide means for both humans and machines to recognize and re-use them in a range of business processes.
In business-to-business exchanges in most vertical business sectors, draft contract documents for a propostd or contemplated transaction are created, exchanged, and revised during a period of negotiation. The contract documents may be customized and carefully negotiated or they may be forms that involve no negotiation at all. Contract negotiations typically involve humans, but automated negotiating "agents" are being developed that allow machines to negotiate and "agree" upon contract terms. Once the contract terms are finally agreed upon, representatives of the private companies or government agencies involved sign the contract documents to indicate their acceptance of and mutual agreement regarding the terms. Contract administrators or managers within the organization then see that the contract is performed. In business-to-consumer exchanges, form contract documents ordinarily are prepared and presented by a business organization to a consumer for acceptance by the consumer. There is little, if any, negotiation of the form contract documents or of their terms. Once the consumer indicates acceptance of the contract terms, contract administrators or managers then see that the contact is performed. In person-to-person exchanges, form contract documents are prepared and exchanged. There may be negotiation of the contract terms, and once the contract terms are finally agreed upon, the persons involved sign the contract documents to indicate their acceptance of and mutual agreement regarding the terms. The organization and sequence of information in contract documents varies widely. Generally, information identifying the contracting parties appears at the beginning of the document. The contract terms, promises, and obligations of the parties appear in the middle of the document in clauses, paragraphs, or form fields. Finally, a date and the signatures of the parties appear at the end. Contract documents contain text structures that are substantially similar to text structures appearing in non-contractual documents, such as paragraphs, titles, quotations, lists, and similar text structures. A standard XML syntax for contract documents should include the core text structures and core semantic terms, such as "party" and "date," common to most contract documents. Contract documents also frequently incorporate other separate documents by physical attachment or simply by a description of and reference to the separate document. Thus, a single electronic contract may actually consist of several separate electronic documents or files. A standard XML syntax for electronic contract documents should allow for incorporating other separate electronic documents or computer files by reference and/or incorporating such separate documents by other means. XML contract documents will be used and exchanged primarily in web-based internet and intranet environments. A standard XML syntax for contract documents must be compatible for use with web applications software and components, such as web servers, web browsers, web services applications, and similar applications. There are a family of standards applicable to XML technologies. These standards, issued as recommendations by the World Wide Web Consortium (the "W3C"), are referenced below. A standard XML syntax for electronic contract documents must conform fully to all applicable W3C XML-related recommendations. XML contract documents also must be compatible with XML-compliant processing software and tools, such as XML parsers, XSLT processors, XML document editors, XML content management applications, and similar XML applications. Such tools and applications will be used to create and process XML contract documents. A standard XML syntax for contract documents should satisfy the following general requirements:
To facilitate efficient management of XML contract documents, a standard eContracts XML syntax should provide for markup of metadata about the document satisfying the following:
Structures appearing in and common to contract documents, such as lists, tables, paragraphs, quotations, defined terms, titles, and similar text structures are substantially similar to text structures appearing in non-contractual documents. To promote the efficient creation and publication of XML contract documents, a standard XML syntax for contract documents should provide for structural markup satisfying the following:
Although semantic business vocabularies vary across different vertical business sectors, there appear to be a number of common core semantic contract terms that apply broadly to contracts in many different business contexts. To promote the efficient creation, management, and exchange of XML contract documents, a standard XML syntax for contract documents should provide for semantic markup of at least the following contract terms:
A. Committee Members (Non-Normative)The following individuals were members of the OASIS LegalXML eContracts Technical Committee during the formulation of this document:
B. NoticesCopyright - The Organization for the Advancement of Structured Information Standards [OASIS] 2001, 2002, 2003. All Rights Reserved. OASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS's procedures with respect to rights in OASIS specifications can be found at the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification, can be obtained from the OASIS Executive Director. OASIS invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to implement this specification. Please address the information to the OASIS Executive Director. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to OASIS, except as needed for the purpose of developing OASIS specifications, in which case the procedures for copyrights defined in the OASIS Intellectual Property Rights document must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. OASIS has been notified of intellectual property rights claimed in regard to some or all of the contents of this specification. For more information consult the online list of claimed rights. C. Intellectual Property RightsFor information on whether any patents have been disclosed that may be essential to implementing this specification, and any offers of patent licensing terms, please refer to the Intellectual Property Rights section of the LegalXML eContracts TC web page ( http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=legalxml-econtracts ) Normative[RFC 2119] S. Bradner. RFC 2119: Key words for use in RFCs to Indicate Requirement Levels . IETF (Internet Engineering Task Force). 1997. [XML] T. Bray, J. Paoli, C.M. Sperberg-McQueen, E. Maler. XML 1.0 Specification (2nd ed. October, 2000) . W3C (World Wide Web Consortium). 2000. Other[CSS2] B. Bos, H. W. Lie, C. Lilley, I. Jacobs. Cascading Style Sheets, level 2 (CSS2) . W3C (World Widt Web Consortium). 1998. [XFORMS] M. Dubinko, L. Klotz, R. Merrick, T. Ramon. XForms 1.0 . W3C (World Wide Web Consortium). 2003. [XLINK] S. DeRose, E. Maler, D. Orchard. XML Linking Language (XLink) Version 1.0 Recommendation . W3C (World Wide Web Consortium). 2001. [XMLENC] T. Imamura, B. Dillaway, E. Simon. XML Encryption Syntax and Processing . W3C (World Wide Web Consortium). 2002. [XML-NAMES] T. Bray, D. Hollander, A. Layman. Namespaces in XML . W3C (World Wide Web Consortium). 1999. [XMLSCHEMA-1] H. Thompson, D. Beech, M. Maloney, N. Mendelsohn. XML Schema Part 1: Structures . W3C (World Wide Web Consortium). 2001. [XMLSCHEMA-2] P. Biron, A. Malhotra. XML Schema Part 2: Datatypes . W3C (World Wide Web Consortium). 2001. [XMLSIG] M. Bartel, J. Boyer, B. Fox, B. LaMacchia, E. Simon. XML-Signature Syntax and Processing Recommendation . W3C (World Wide Web Consortium). 2002. [XSLT] J. Clark. XSL Transformations (XSLT) Version 1.0 Recommendation . W3C (World Wide Web Consortium). 1999. [XSL] S. Adler, et al. Extensible Stylesheet Language (XSL) Version 1.0 Recommendation . W3C (World Wide Web Consortium). 2001. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
