[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 12 Recommendations, plus JasonProposal.pdf
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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]