12 Recommendations, plus JasonProposal.pdf

["John McClure" <jmcclure@hypergrove.com>]

Hello,
Here are recommendations for consideration by the TC as we prepare to develop
normative material. The attached PDF contains my response to Jason's (and to an
extent, Peter's) proposal.
Regards,
John

12 RECOMMENDATIONS
======================
1. The eContracts TC establishes that  there are distinct datastreams
corresponding to a contract proposal, a contract offer, and an executed
contract. Their information sets overlap, however their XML representations must
vary considerablly for technical and legal reasons.

2. Both contract offers and executed contracts require a signature of one or
more parties. For legal reasons, these datastreams are required to be
presentation-oriented XML datastreams. The XML dialects XHTML, XSL-FO, Xforms,
and SVG are presentation-oriented XML dialects that require no prior
transformation when presented for display by browsers implementing W3C
standards. These 3 dialects are the only dialects allowed at this time for
encoding of contract offers and executed contracts that are said to conform to
eContracts standards for their XML representation.

3, Contract proposal documents, as a class of documents, are the only candidate
for development of an XML dialect that is fully within the control of the
eContracts TC. Other implementation vehicles for contract proposal documents may
include presentation dialects named above.

4. Specific instances of a type of contract proposal may have an associated,
fixed, DTD, XML Schema, or Relax NG artifact. These artifacts provide validation
for instances of contract proposal documents conforming to that type. The schema
for these documents can be created from representative instance documents by
tools such as XML Spy. These representative instance documents are required to
have been encoded according to the wider standards of the TC. These schema
therefore reference elements documented within the TC's controlled vocabulary of
element and attribute names, and element and attribute values, but are
specialized for the requirements of the document type representing the contract
type.

5. The TC shall create standards that utilize and accommodate the use of XML
Namespace within eContract datastreams, both for presentation and
non-presentation contract documents.

6. The TC shall endevour to reuse and to expand as necessary the eFiling TC's
legal document envelope structures and standards.

7. The TC shall endevour to create a namespace that fully conforms to the
Resource Description Framework standard. This includes adoption of Universal
Resource Identifiiers for unique identification of clauses and other information
within a contract proposal, contract offer, or executed contract. XML
identifiers ("id") shall not be acceptable for unique naming purposes.

8. The TC shall endevour to create standards for the indexing of contract
documents using the Dublin Core elements as a baseline.

9.Citations written in XML to contract clauses, sections, or documents must
resolve to presentation-based elements. Identifiers for any information elements
carried forward unchanged from a contract proposal to a contract offer to an
executed contract must be preserved across the three renditions of the contract.

10. The TC shall create a formal W3C-conforming ontology representing the
vocabulary deemed within the control and scope of the group.

11. UBL Naming Conventions are compatible with naming conventions common to RDF
applications; XML attribute names and RDF predicate element/attribute names are
lower camel-case, while XML element names and RDF resource names are upper
camel-case. The TC shall adopt these conventions.

12. The TC shall adopt and extend the RDF Proposal for clause structures.

JasonProposal.pdf