OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

legalxml-econtracts message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [legalxml-econtracts] Clause Model Submissions

Hi John,

> Hi Peter,
> It's difficult to postpone facing this issue (of exchanging
> clause numbers) when
> both your proposed DTDs specifically accommodate such exchange.

This reflects our perspectives at this time so it is reflected in the
markup. For that reason, it is fair to put the issue on the table as not
being closed off by the examples we have provided. However, it would be a
pity if the issue distracts us from the real issue at hand; the underlying
hierarchical structure. Whether we end up including or not including numbers
can be dealt with later. As I mentioned, I think its a difficult issue and
one we will solve only when we look at the needs of users who expect to
exchange XML documents.

> Personally, I
> fully support excluding these numbers from Clause Model
> solutions, deferring
> their generation to the time that the "final" presentation form
> of a contract is
> created -- I believe that this stance CLARIFIES the exchange model we are
> promoting, that is, it is a clear statement that we are NOT exchanging
> presentation information, but rather are focused on the exchange
> of information
> used to generated the presentation artifact.
> I'll answer your other stated concerns in this way. (a) There's not much
> difference between generated clause numbers and generated page numbers --
> support zero or all to be consistent (b) actually, it's easier
> for software not
> to worry about exchanging and maintaining generated presentation
> information
> during the drafting phase (c) Cross-references are best done
> during drafting by
> way of URI references, not by text names; within the presentation
> documents,
> references of course would contain *both* uri's and text, that is, the
> information necessary to support the HTML <a> element.

One point only at this stage. John, there is absolutely no point in
discussing URIs, HTML tags or any other specific implementation at this
point. We have to start with user needs and work down from there.

I strongly disagree with your contention that clause numbers are
presentation and similar to page numbers. I do not regard them as
presentation at all, even though they change during the drafting process
(just as the text is changed). The fact that they are generated as the draft
changes is a convenience. They are there as a citation mechanism and allow
parties to unambiguously refer to specific provisions of the text and to
support cross references within the text, regardless of publishing medium.
They will become fixed for all time when the contract is signed. As such, I
argue that they are an indivisible part of the text of the contract (or
draft). This is not the case with page numbers.

Two parties negotiating a draft contract need to be able to refer reliably
to the provisions of each draft. They would only use page numbers for this
if they both happened to have the same print outputs in front of them. They
would not expect them on a web page display (often that is why people use
PDF). People understand the ephemeral nature of page numbers and expect they
may vary on any two printouts of even the same draft from different
printers. However, they expect numbers of provisions to be much more robust
so that any document user should be able to print or view the document on
line and see exactly the same provision (clause) numbers for a given draft.
Only in the most superficial way are page numbers and clause numbers the
same from a user perspective. They are similar only in the sense that they
can be generated by computer software. This has nothing to do with their
function and relationship to the text.

The first issue will be to determine the clause numbering functionality
people want from XML documents. Once we have worked this out we can figure
out how to achieve it.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]