RE: [legalxml-econtracts] XHTML 2.0 issues

["John McClure" <jmcclure@hypergrove.com>]

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.