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: Strict XHTML 2.0


To handle some of the problems that Peter advises, are these proposals for a
"strict" subset of XHTML 2.0.

1. A <section> element contains only <h> and <p> elements.
2. A <p> element contains text content, <l>, <img>, <table>, and list and inline
elements.
3. A <enum> element is new -- it represents an item in an inline list.

Note there is no "container" for <enum> elements -- that would foremost break
the definition of an "inline" element. It's named <enum> because I believe that
the items in an inline list are more correctly called "enumerations"; lists have
a vertical orientation while enumerations flow with the text of their
paragraph's text content. Their numbering by default is to be restarted within
the <enum>'s parent <l> or <p> element, but there should be attributes on the
<enum> element for control formatting details. I have never seen bulleted inline
lists, so there is no doubt that the <l> is overloaded with interpretation of a
<ol>, and the <enum> has the interpretation of a <li> -- how is that done --
Modular XHTML's "class" declarations I think are tied in with the CSS display
classes, so it may be easy to associate these with the right default behaviors.

I acknowledge that seamlessly converting a group of items within an inline
enumeration into items within a block list, is not possible in this proposal.
Nevertheless, I see that issue more as an application issue, rather than an
information exchange issue -- my expectation is that most decent editors will
have a general interface for converting elements of one type to another as the
need arises during any cut and paste operation that occurs, so it's definitely
suboptimal to strive for all elements used in both contexts, to have the same
name.

The second point worth noting about the proposal is that the problem of
accidentally using a <ol> rather than a <section> to represent a structural
<item>, is addressed by forbidding <ol> elements as children of a <section>
element. This strict interpretation of XHTML places all block lists into a
container that requires text content or inline elements. This means that every
block list must be accompanied by "explanatory" text content. Also, <p> elements
must always begin with text content or inline elements. These rules apply
equally to other block elements -- <img> and <table> -- that may only occur in
the context of a paragraph element; a <p> element is essentially defined by its
text content, and hence text content is required content of a <p> element.
Regardless of the order of elements within the <p>, a different display order
can nevertheless be defined by CSS positioning attributes attached to the list,
<img>, <table>, <div>, or <l> children of the <p>.

Off the topic is the notion of a <pg/> element, an empty element that represents
a page-break -- this would be very useful to many applications, and would be
easy for the user to enter in any inline-element context. The <br/> element,
defined also as an empty element,  had so many obvious and useful applications,
that it has been formalized as an <l> block element. They were lucky on that
one, because the <l> element exists exactly on the boundary of the block world
and the inline world so its interpretation can slosh around a little.

Regards,
John


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