RE: [legalxml-econtracts] eContracts TIME CHANGE ALERT and Agenda Clarification

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

Hi Jason,
We seem to share the view that SVG is the "best" XML encoding for a contract in
order to faithfully reproduce its look across client systems. Unfortunately, we
seem to arrive at different consequential action statements. To me, our standard
should as a primary goal standardize how that SVG (or XHTML) datastream is to be
encoded. Yours seems focused on first creating non-presentation material until
SVG becomes an obvious requirement. But non-presentation material is metadata
when a presentation is at issue, and that contract metadata should conform to
the well established W3C standard for metadata - the Resource Description
Framework.

As our first priority, I suggest that XML-encoded evidentiary contracts should
be treated as comprehensively as possible, particularly when we *know* that many
parties will be happy to encode their contracts in XHTML or SVG, whether
natively or by action of an XSL-T stylesheet against their own XML dialect, or
MS XML, or Docbook, or an XForm, or an XSL-FO (or even voice) . I frankly don't
grasp why the H/M dialect should be our highest priority in the face of the far
more likely prospect of the industry generating pretty standard presentation
datastreams.

The paper implies a logic that (a) XHTML+CSS is a poor choice for an evidentiary
contract, on grounds of image fidelity, so we should not abet it; and (b) the
content within an "ideal" evidentiary contract is unlikely to be linkable for
the foreseeable future because it can't be well-displayed, therefore means (c)
our standard should apply to non-presentation material, such as the H/M dialect.

Instead I suggest that our initial requirements focus on only:

(1) presentation material that is acceptable to parties as evidentiary material
(as self-evidenced by the presence of dsignatures). The standard should focus on
how to structure such material for proper, standardized, linking to its internal
content. Links may be to content of either a structural or semantic nature.

(2) metadata for the contract deemed relevant to its formation, administration,
and mediation. It is vitally important to note that this metadata is
functionally dependent on a standard for linking [see (1)], because the metadata
refers to (links to) internal content that is available only after the contract
has been fully "assembled" into a presentation datastream. Anything less
invalidates the notion of metadata referencing the agreed-upon contents of the
contract.

In short, I think the H/M model, though elegantly conceived, is the wrong
emphasis for our first specification. We should demonstrate that we fit well
with others; and that we are staying within our legitimate scope of interest. In
the first case, this means we support and conform to others' standards, and in
the second case, that we have the self-restraint to keep away from document
authoring and assembly.

For tomorrow's call, the heart of my (technical) argument as to why we should
re-consider our preliminary consensus to exclude presentation issues from our
scope, is this: my demo shows that placing id's on non-presentation elements is
substantially irrelevant to linking to presentation elements.

If anyone decides this is a fruitful approach, then it'd be great to hear so. I
think we can make greater strides as an organization if we keep it simple. I
don't see why a <lgl:Block> element, and a "lgl:names" attribute, won't be
adequate as our core standard with respect to presentation material. Easy to
explain, and asks the world to change the least.

Regards
John

<lgl:Block names='NonCompeteClause'>
	<p>simple<p/>
</lgl:Block>