Quasi Functional Requirements

Hi,
There seemed to be some 
uncertainty about what I posted for technical requirements, so here it is again, with some additional content now 
inserted. I offer this with the thought that it could possibly be useful in the 
Requirements document. As a side note, I am wondering about the impact of links 
to the Scenarios in the Requirements document -- they'd have to be made public, 
and I'm not recalling that the TC has ever discussed doing so. Also, the links 
themselves are now made to posted 
messages, which doesn't seem like the right thing to do - 
John

Table of Contents 

  5. Technical Requirements. 
  
  
    5.1. Objectives of Technical 
    Requirements. 
    5.2. eContracts Technical 
    Roadmap. 
    5.3. Related XML Standards. 
    5.4. eContracts Core XML Technical 
    Requirements. 
  

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. 

5.1. Objectives of Technical Requirements. 

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, 
  

5.2. eContracts Technical Roadmap. 

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.

  

5.3. Related XML Standards. 

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. 

5.4. eContracts Core XML Technical Requirements. 

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. 

Other pictures

And, for the section that 
introduces the concept of an "event" that is described as contemplated by a 
contract: