Table of Contents
5. Technical Requirements.
An XML representation of an "eContract" cannot be constrained to a single dialect designed by this Technical Committee. An "eContract" may be represented using any XML dialect mutually agreed-upon by the parties to the contract. So as to achieve the TC's functional goals for the use of contractual material in contexts unrelated to its authoring, the TC establishes standards that accommodate contractual material created in other, arbitrary, XML dialects.
An "eContract" is not construed to represent the entire legal agreement that exists between its parties. An "eContract" represents a single legal instrument that, often only in concert with other legal instruments, constitutes the entirety of a legal agreement. This Technical Committee makes no requirement that an "eContract" must be representative of a "four corner" legal instrument documenting (some aspect of) a contractual relationship between its parties.
The operating definition of an XML-encoded eContract naturally relates more to the definition of a contractual legal instrument than to the definition of a legal agreement. Legally relevant information is implicitly represented by the legal instrument when it is recorded on a paper medium. When parties to a contract instrument indicate their assent to the legal instrument, they are giving their assent not only to the information represented within the contract, but also to certain meta-information which devolves implicitly from the fact that the instrument is recorded on paper:
- that the representation of the content of the contract instrument, is acceptable;
- that the medium used to record the contract instrument, is acceptable;
- that the layout of the content within the contract instrument, is acceptable;
- that subsequent representation of the instrument's content, is acceptable;
- that the method used to authenticate assents by parties to the contract instrument, is acceptable;
- that material "included by reference" (either physically attached to the contract instrument, or as a citation to documents of record), is acceptable.
In short, both the XML dialect used to represent the content of the contract instrument and the meta-information about the contract are subjects of mutual assent. Failure to duplicate such meta-information within a digital eContract renders it insufficient as a vehicle for an authentic legal contract instrument. This section discusses the technical aspects of these requirements, regardless of whether the XML datastream is encoded or not using the XML dialect designed by this Committee.
For instance, parties to a digital eContract can explicitly accept that the "look and feel" of a subsequent display of the contract, using specific software products and hardware configurations, may vary in ways insubstantial to the agreement. An eContract needs to make the mutualities of assent that are implicit in the paper medium, as explicit as possible in the digital medium.
This section identifies technical objectives to be achieved by future standards related documents published by the TC.
- Representation
Technical implementation standards are required to represent all contract content and contract meta-information to which contract parties historically have provided their assent. Standards are required to minimize the repudiability of eContracts datastreams as representative of a legal contract instrument.
- Integration
Technical implementation standards are required to be integrated with, and not duplicative of, other extant standards efforts.
- Modularization
Technical implementation standards are required to be developed in a modular manner. The TC should establish overall a family of standards that relate to each of the different functional and legal states of a contract instrument.
- Performance
Technical implementation standards should encourage the overall performance of end-user applications,
This section provides a roadmap for the design of XML standards for eContracts, and refers to the following diagram.
- Negotiation Datastreams
Negotiation datastreams are not contracts-of-record for an agreement. These datastreams have no presentational component functionally significant to standardize. Therefore, these datastreams are found only within LegalXML envelopes labelled "Proposal".
Two types of Negotiation datastreams exist: the draft contract's content, and metadata about the draft contract. The metadata includes elements considered relevant by parties to the authoring of a contract offer, and may recount or define the workflow events associated with the value of any contract parameter and or with acceptance of the contract by its parties.
A Negotiation datastream may reference draft contract content that is not physically located within the draft contract, such as content that might be located within a separate Contract Template datastream or Boilerplate Clause datastream. A Negotiation datastream is generally anticipated to be formatted for presentation by a user's own contract authoring application, in a manner not agreed by all parties.
- Presentation Datastreams
Presentation datastreams are those transmitting significant presentation information. These datastreams are found within LegalXML envelopes labelled "Offer", "Counter-offer", "Acceptance", or "Rejection". The envelope is anticipated to be able to identify any legal instruments that are previous offers or counter-offers. A Presentation datastream may contain any dialect that has been standardized with a User Agent definition. This includes any custom dialect of XML that is represented using CSS formatting; XHTML (with or without XForms); SVG; and XSL-FO.
As a legal matter, presentation of the content of a contract is integral to its acceptance; acceptances are to be indicated by digital signatures. Accordingly, all Presentation datastreams that are to be construed as offers, counteroffers, acceptances, or rejections, are to be (digitally) signed by at least one party. Signed, non-presentation datastreams are legal oxymorons. However, unsigned, presentation datastreams are not necessarily legally meaningless, if the parties mutually accept other verifiable methods to indicate assent by parties.
Further, a Presentation datastream may not reference contract content that is not physically located within the datastream, with one exception: reference may be made to legal instruments of record.
Two types of metadata about a Presentation datastream can exist: required metadata about the contract's presentation characteristics; and optional metadata about its negotiation. Metadata about the contract's presentation characteristics is to be equally associated with assents as the content of the contract, is. Metadata for presentational characteristics should be represented using Dublin Core elements, whether duplicative of any metadata in a LegalXML legal instrument envelope or not.
Negotiation metadata that is a subject of the contract (that is, when parties to the contract have agreed to accept the metadata as a valid representation of the extent of their assent to contract terms) is to be equally signed by the parties to the contract.
- Administration Datastreams
This datastream records actual events that occurred pursuant to the contract and or pursuant to the encompassing legal agreement to which the contract relates. The TC should create a standard set of XML elements that represent these events so that subsequent contractual documents, such as contract renewals, can reference relevant information.
- Mediation Datastreams
The TC should establish a standard set of XML elements that are to be exchanged from the negotiation, contract, and administration datastreams with jurisdictional or mediation agents.
This section identifies the role that other standardized XML protocols are anticipated to fulfill in the standards related documents published by the TC.
- XML
eContract standards should use XML text entities to represent "boilerplate" text; the Committee should create a separate standard for "boilerplate clauses". DTDs are to be created for all standards, however only to the extent allowable by the standard syntax for DTDs. No external namespace elements may be defined in DTDs published by this committee for non-metadata documents. The DTDs for eContracts metadata documents should define the elements of the Resource Description Framework (rdf) namespace.
- XML Namespaces
The TC allows elements defined by namespaces, including those defined by this TC, within the body of all eContracts datastreams, if acceptable to the parties.
- CSS
The Cascading Stylesheet Language (CSS) is used to format arbitrary XML datastreams. The existence of a CSS stylesheet, or a reference to a CSS stylesheet, within an eContract datastream is indicative that the datastream is an eContract (Presentation) Contract datastream.
- XHTML
The Extendable Hypertext Markup Language (XHTML) is an XML dialect for which the W3C has defined User Agent behavior, and is therefore a presentation dialect. To provide linking to contract material within an XHTML datastream, the TC should designate one or more elements that are to be located in the XHTML datastream to indicate (1) that it is an eContracts datastream, and (2) that indicates citable components of the eContracts datastream.
- SVG
The Scalable Vector Graphics Language (SVG) is an XML dialect for which the W3C has defined User Agent behavior, and is therefore a presentation dialect. To provide linking to contract material within an SVG datastream, the TC should designate one or more elements that are to be located in the XHTML datastream to indicate (1) that it is an eContracts datastream, and (2) that indicates citable components of the eContracts datastream.
- XPATH
The TC adopts XML Path expressions (XPATH) as the proper method for positional references to elements within eContracts; and for elements commonly identified using the XML id attribute, as long as that element has an ancestor element that is labelled with a valid rdf:ID attribute.
- XSL-T
The Extensible Stylesheet Transformation Language (XSL-T) is not defined by the W3C as a User Agent language; it is a transformation language. An eContracts datastream that is an XSL stylesheet; that contains an XSL stylesheet; or that references an XSL stylesheet is not a Presentation datastream. At most it can be used as a representation of a "Proposed" contract.
- XSL-FO
The Extensible Stylesheet Flow Objects Language (XSL-FO) is defined by the W3C as a User Agent language; it is not transformative. An eContract datastream that are tagged in the XSL-FO dialect may be representative of an "Offer", "Counter-offer", "Acceptance", or "Rejection" datastream.
- XForms and XML Events
The TC should define the use of XForms, an XHTML 1.1 module, for the markup of "form" contracts. A companion XHTML 1.1 module, XML Events, defines event-based handlers that can be attached to elements in an XML datastream. The TC should define the use of XML Event handlers with reference to the events that are defined or contemplated by an legal contract. - RDF
Tagnames and structure in all metadata should conform to fully striped RDF syntax. All names for metadata resources identified by the TC are to be specified using UpperCameCase notation, while all their attributes (their properties) are to be named using lowerCamelCase convention. Names of resources alternate with names of their properties as the standard pattern of XML element content models standardized by this TC. All resource names and property names are to be defined as XML elements within DTDs, XML Schemas, and RDF Schemas. All property names are additionally to be defined as the names of XML attributes for the XML resource elements.
All metadata resources defined by this committee are to be identified with a Uniform Resource Identifier (URI) that distinguishes it uniquely within the context normally of a Universal Resource Locater (URL), or of a registration authority for a Universal Resource Name (URN). XML "id" attributes are acceptable as URI fragment identifiers within the scope of a URI-attributed ancestor element.
The TC should define resources of two types: (a) resource "class" resources, such as a "UnilateralContract" and "NonRepudiationClause" and (2) resource "instances", such as specific governing authorities for contracts. The TC can either define these resources itself, or standardize on resources defined by LegalXML or other standards organzation.
- XML Schema
The TC should define its XML schemas using this W3C dialect.
- Digital Signatures
The TC should use the W3C Digital Signature standard for conforming signed legal instruments.
- Dublin Core
The TC should provide standards relevant to the fourteen elements standardized as the Dublin Core. These elements are used to index the eContract Contract datastream; and to transmit all meta-information concerning its presentational characteristics.
Dublin Core elements represent metadata about the Contract Datastream, uniquely with respect to metadata about any eContract Metadata datastream. The XML namespaces used by these datastreams should be indicated by Dublin Core elements.
- LegalXML Standards
The "envelope" architecture and XML protocol defined by the LegalXML Court Filing Technical Committee should be adopted as a foundation for eContract XML standards. It is anticipated that declaration of the datastream as a "legal contract" and its status as a "Proposal", "Offer", "CounterOffer", "Acceptance", or "Rejection" should be provided by the envelope to the eContract XML entity.
- OASIS Standards
eContract datastreams tagged using OASIS standard office and document publishing dialects. because they have no associated User Agent definition, are purposed as "proposed" contractual material.
- ISO Standards
The TC should use ISO standards for date, time, country, and language quantities.
- IEEE Standards
The TC shall use IEEE standards for URIs. The TC should integrate its ontology-related definitions and standards with those developed by the IEEE such as the Suggested Upper Merged Ontology (SUMO).
- ECMA Standards
The TC should create standards that enable the development of scripting languages relevant to the content of eContracts.
- UN/UBL Standards
The TC should create standards that enable the incorporation of commercial elements designed by the United Nations.
- Other Standards
The TC may integrate with other standards determined worthwhile to the community, either before or after integration with the standards listed in this section.
This section identifies core technical requirements for standards related documents published by the TC.
- Digital Integration
All content of a signed contract shall be integrated within the single XML entity representing the signature(s). All information to which one historically assents in a contract should be accommodated within this signature envelope. The signature envelope contains a LegalXML envelope, in which all material included-by-reference should be either physically included, or be a reference to material with permanent legal stature. The LegalXML envelope primarily contains contract material, and sanctioned metadata.
- Separation of Metadata
All metadata (except identifiers) about an eContract or its content should be located in an XML entity separate from the contract content. Metadata representative of an ascertained state of a contract should be transmittable separately from metadata descriptive of an earlier or future state of the contract content.
- Contract Instrument Artifacts
Contract "proposals" may be represented using any XML dialect agreeable to the parties. Contract offers, counter-offers, acceptances, and rejections may be represented only using XML dialects designated as User Agents by the W3C.
- Representation of Metadata
All metadata about an eContract or its content is represented using the Resource Description Framework (RDF) dialect. This dialect allows the inclusion of elements that are defined by other namespaces. The eContracts TC shall define a namespace for elements that are specific to the context of contractual legal instruments.
- Citation to Content
All contract content and contract metadata should be citable either positionally or by unique identifier. Citations of a logical nature, such as to a subclause, and citations of a physical nature, such as a page of text, should be accommodated by TC standards.
