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

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"
	(2) publishing a LegalXML module with additional elements and attributes as
	(3) publishing a "tidy" stylesheet to normalize errant XML into structures we
	(4) publishing a LegalXML namespace for use in RDF documents describing the

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?


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