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: Pruning XHTML2 for eContracts


I have read Jason's "Pruning XHTML2" document and the exchanges between
John and Jason.

I apologise for not being able to make a more detailed technical proposal.
I am out of the country until late January and am not able to deal fully
with all the issues. I have a few quick observations for consideration. I
regret I won't be able to attend the next teleconference on 14 January. I
should be OK for one 2 weeks after that.

1. Pruning XHTML 2 for e contracts
I am not yet convinced that it is necessary to prune XHTML 2 but would not
rule it out completely. The thing that makes me reticent is that if XHTML
2 does find widespread use, it will be used for more than contracts in
legal offices and similar places. I don't see much point in pruning it
just for contracts.

On the other hand, if formal conformance to the XHTML 2 standard is not
important (see my point 7 below), there is no real reason why we could not
throw redundant bits away to simplify it before adding our own modules. At
this stage, I don't have a strong view one way or the other.

I think much of the problem will be handled by the editing applications. I
think it likely that the editor will make it easy to insert the core
elements and users need not bother about the others unless they have an
uncommon situation.


2. The core user group
I have always assumed that it will be hard to get lawyers to create XML
documents directly but that there will be a gradually expanding base out
from the specialist precedent managers and such like. XHTML might
facilitate this if it allows enterprises to begin to think about using
structural markup more extensively because the cost benefit equation
changes dramatically. For this reason, I have proposed that we need to
treat lawyers as part of the key user group.
If we don't envisage lawyers as being part of the target user group, why
are we bothering to try to develop a standard?
My questions to John McClure:

 A. What is your definition of the key target user group?
 B. If its not lawyers, why is it important to use XHTML 2 and to insist
on Host Language Document Type conformance? Put another way, what
proportion of contract documents need to be directly rendered in a web
browser?


3. Proposal for a "clause" element in XHTML 2
My reading is that John proposes this.
I am completely opposed to this. The section element performs this
function. A clause element will just duplicate the section element.


4. Front, back and schedule/attachment content
We do need to figure out how to deal with these components. I see no
reason why we cannot add elements to deal with this, if needed. We found
with our own schema that it was not satisfactory to use the equivalent of
the section element for all these functions. It is convenient to have a
different content model sometimes. For example, we found we needed to be
able to add a complete document as an attachment. Without having access to
the XHTML 2 material, I don't know exactly how it works but suspect it
does not allow this.

I would support a proposal to the W3C to deal with these if we could put
forward a common proposal.


5. Other problems with XHTML 2
Jason refers to various problems with the draft XHTML 2. Two key ones are
the excessively loose content models that will make it hard to create
consistent markup and the less than optimal list model. We have discussed
the list model before. As you know, I don't like it. My support for XHTML
2 is not because of its techical superiority.

I see no reason why we could not produce a tighter version of XHTML 2 that
removed some of the laxity that may cause problems, eg, allowing PCDATA in
section. This should not conflict with the standard in any material way,
if that is a problem.

I would support representations to W3C to see if we can improve the list
model. Retention of the HTML 1 model is unfortunate. We would need to
consider this in more detail, particularly in the context of how we deal
with component numbering generally. I expect our representations will fall
on deaf ears but we will achieve nothing if we don't try.


6. Jason's simple paragraph proposal
I remain completely opposed to this as part of an econtracts standard. I
believe we do need a true paragraph model.


7. Conformance to the XHTML 2 standard
Apologies if I don't use the correct terminology here.

It is still not clear to me why it is important to maintain formal
conformance to the XHTML 2 standard. John does advance some arguments but,
again, this seems to depend on our user community.
Jason seems to be convinced that conformance is important but, unless I am
missing something, I have not seen substantial reasons for it.
To me, the value of XHTML 2 is that is will give us a core structural
markup that will become familiar to eveyone and that will be built into
applications. From that perspective, we really only need a few core
elements from XHTML 2.
I would like to explore this issue further as it may help us to decide
what sort of changes we might want to seek from the W3C to avoid having to
make non conforming customisations.

Is formal conformance to the XHTML 2 standard important mainly for direct
web browser rendering or for other reasons?
Can we have a discussion on the practical (user level) consequences of
either pruning elements or adding elements to the standard? What bad
things will happen and to whom if we don't meet particular conformance
levels?

Regards
Peter Meyer




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