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


Jason,
I am interested in the fastest and widest adoption of a LegalXML standard for
(contractual) legal instruments. I believe that conforming to the Host Language
Document Type (HLDT) will facilitate a much faster and wider adoption than
conformance to the Integration Set Document Type (ISDT). I say this essentially
because I am confident that popular browsers will be modified to display HLDT
documents. I am not so confident that popular browsers will be modified to
display ISDT documents until the market "has spoken" that a real need exists for
ISDT documents. I do not want to gamble that our spec, or specs from other
groups, constitute a formidable enough "market" to make their costs of
implementation worthwhile.

I want our standard implemented widely in a 3 year timeframe, not an 8 year
timeframe.

You mentioned some advantages, with comments:

1.	[minor advantage] Common web browsers will be able to display a Host Language
document. For elements it does not recognize, it will display the text, although
it will probably display the raw text in any elements it doesn't recognise.

	Your use of the term "raw text" is slightly misleading; perhaps it could say
	the formatting of the (recognized) parent element is applied to the content
	of the (unrecognized) element in the absence of a CSS directive that can
	be associated with the the (unrecognized) element, either through the
	element name or one of its attribute values.

	Gee, I think that this is more than a minor advantage. Consider the alternative
	should there not be builtin formatting for the <section> element -- all users
on
	all continents would be forced to specify a stylesheet for all documents!

2.	[advantage] Assist with market acceptance of TC work

	Yes, allies are invaluable !

3.	[minor advantage] Willingness to learn XHTML2 amongst developers (but no
familiarity, much less amongst contract managers or lawyers).

	We don't agree on our target audience I guees... I think the audience for our
	technical specification are the same people who read all the other W3C
	specificiations. I do think this an important advantage, because if our
standard
	is merely XHTML 2.0+LegalXML module, then there'll be less resistance, more
	ready acceptance, among the readers who can "relate" it to a knowledge base
	they have already developed.

4.	[advantage] XHTML2 includes an XForms module.  XForms represents a possible
way to tie the structural representation of a contract to the data which needs
to be extracted from it for various downstream applications.  To the extent that
the TC uses XHTML2, XForms is a natural fit, which is good.  Note however that
the TC does not need to use an XHTML2 Host Language in order to be able to use
XForms, should it wish to do so.

5.	[advantage] Content reuse from other XHTML 2.0 documents (snip about 1.0
docs).

6.	[minor advantage] We can assume there will be a class of editors that are
designed specifically to make it easy to edit strictly conforming XHMTL 2.0
documents.  We can speculate that there may also be a class of editors that are
developed specifically to make it easy to edit XHTML 2.0 Host Language
documents?  It is probable that such editors would require some level of
customisation before they are easy to use, presumably only for extensions (refer
Host Language Conformance definition #4) and additions (refer Host Language
Conformance definition #5).  Query whether this would be less customisation than
a generic editor (pre-configured by the vendor to work with XHTML2, DocBook etc)
would need.

	I think the same thing occurs for editors as for browsers -- they'll tackle
HLDT docs
	first, and then later --- maybe --- do ISDT documents.

So let's target HLDT conformance!
John

>-----Original Message-----
>From: Jason Harrop [mailto:jharrop@speedlegal.com]
>Sent: Monday, January 12, 2004 2:48 AM
>To: Legalxml-Econtracts
>Subject: RE: [legalxml-econtracts] Pruning XHTML2 for eContracts
>
>
>Hi John
>
>Thanks for taking the time to read the paper.
>
>I must say i'm surprised you take such a hard line against pruning.
>
>Of course a "decent editor" could be customised to make an inappropriate
>document type easier to use.  But why impose this burden on tool
>providers, when
>it can be avoided by using an appropriate DTD (ie pruned XHTML)?
>
>Perhaps the benefits of Host Language Conformance do outweigh the benefits of
>pruning (though i doubt it).
>
>It would be helpful if you could spell out what you see as the primary
>benefits
>of Host Language Conformance, and then which of these would be missed if we
>pruned the language.
>
>thanks
>
>Jason
>
>
>> Hi Jason,
>>
>> Some thoughts about your paper. Generally, I guess we've got different
>> perspectives on this process. I see the XHTML 2.0 specification as something
>> that is to be BUILT UPON, not something that is to be STRIPPED DOWN. For
>> instance, you cite a number of elements and a "sea of attributes"
>whose presence
>> you implicitly believe will cause rejection of our specification by
>> user-attorneys (not our key audience, in my opinion). However, I believe the
>> basis for your complaint about "irrelevant" elements and attributes is an
>> application-level concern; a decent editor could very easily
>rearrange the list
>> of pertinent child elements to reflect those most recently requested by the
>> user. Or (as I do in my product) use ICONS which insert new
>instances of common
>> elements -- these can be added/removed from the icon menu and, or
>course, these
>> are backed up by an exhaustive list of DTD elements
>>
>> In short, I have to categorically reject the notion of "pruning"
>XHTML of any of
>> its elements and its attributes, merely for the convenience of
>user-attorneys.
>> The impact of such a step -- a "pruned" XHTML2 would not be Host Language
>> conformant -- is antithetic to the advantages you cite for our
>piggy-backing on
>> XHTML 2.0, advantages I definitely do NOT want to jeopardize.
>>
>> Instead, I support
>> 	(1) publishing a guideline on the use of XHTML 2.0 elements and
>"foreign"
>> modules
>> 	(2) publishing a LegalXML module with additional elements and
>attributes as
>> needed
>> 	(3) publishing a "tidy" stylesheet to normalize errant XML into
>structures we
>> recommend
>> 	(4) publishing a LegalXML namespace for use in RDF documents
>describing the
>> contract
>>
>> Beyond that issue, thanks very much for illuminating what's involved for Host
>> Language conformance. I am wondering at what point we'll discuss whether the
>> four items listed above should be our intended work products, maybe even
>> organizing subcommittees for each?
>>
>> Regards,
>> John
>>
>
>
>To unsubscribe from this mailing list (and be removed from the roster
>of the OASIS TC), go to
>http://www.oasis-open.org/apps/org/workgroup/legalxml-econtracts/member
s/leave_workgroup.php.


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