[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [legalxml-econtracts] XHTML 2.0 issues
Well, I don't know about "going back to basics" ... seems a little late for that, Peter. Rather, your note seems perhaps more about avoiding the issues than about resolving the issues. >-----Original Message----- >From: Peter Meyer [mailto:pmeyer@elkera.com.au] >Sent: Monday, August 16, 2004 10:13 PM >To: John McClure >Cc: Legalxml-Econtracts TC >Subject: RE: [legalxml-econtracts] XHTML 2.0 issues > > >With respect to John, we don't have any such clear requirements as suggested >by him because we don't have any requirements at all at this stage. > >Consequently, I suggest it is not productive to debate these kind of markup >issues in that environment. > >I believe that we cannot proceed effectively without going back to basics >and working out exactly what it is we want to achieve. This means starting >right at the top (broadest, business needs) and working down. Fortunately, >we now seem to be set on that course. I would like to confine efforts to >that endeavour so we don't repeat the mistakes of the past any longer. > >regards >Peter > > > > >> -----Original Message----- >> From: John McClure [mailto:jmcclure@hypergrove.com] >> Sent: Tuesday, 17 August 2004 1:34 PM >> To: Legalxml-Econtracts >> Subject: RE: [legalxml-econtracts] XHTML 2.0 issues >> >> >> Folks, >> It seems there's still some indecision about whether the <l> and >> <span> elements >> should be included in the structural model. >> >> For me, it's clear: the line element (<l>) is an important element that >> satisfies a specific need unmet by XHTML 1.1. The <br/> element >> of course does >> not encapsulate at all and needed to be replaced. The user's >> intent is still >> crystal clear, to preface some content with a new line. >> >> We also have an unambiguos requirement for numbering the lines of >> text in a >> contract, We need markup to do that. The <l> element was >> established by XHTML >> 2.0 for exactly this purpose. This has nothing to do with lines >> on a page in a >> document, a styling concern. >> >> As for the <span> element, as for the <div> element, it is not >> much more than >> the equivalent of a so-called "add-in" element. The <span> >> element is an add-in >> in-line element, and the<div> element is an add-in block element. >> Remember, we >> have the same functional 'add-in' requirements as TBL had when he >> designed the >> <div> and <span> elements in HTML 1.0. some years ago. Rolly has mentioned >> 'add-in' requirements several times with regard to marking up >> functionally named >> strings of text. The <span> and <div> elements, together with the >> @property >> attribute, serve precisely this purpose for XHTML 2.0 streams. >> >> It seems overly-analytic to exclude the <l> and <span> elements from our >> structural model, for reason of some ambiguity in some >> situations. I take them >> as given, and will program my applications accordingly, while >> being thankful for >> their wide deployment through the auspices of XHTML 2.0. >> >> 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/members/lea >ve_workgroup.php. > > > >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]