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 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
> 



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