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] XHTML 2.0 issues

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.


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