[no subject]

My thesis in this process is that each of the proposed models represents a
set of compromises to achieve its objectives. None of them meets all our
requirements to the same degree. Ultimately, we will need to identify the
factors which we think are significant and how each addresses them from a
technical and commercial perspective.

I suggested in my posting on 23 November that any new model will now have to
be assessed against the proposed XHTML 2.0 to determine if it provides
sufficient advantages to justify the effort and costs of an alternative
model to something that will likely be "good enough" for most uses and
widely accessible to user enterprises. My position is that it would be worth
proceeding with a new clause model if:

(a) we can produce something that provides significantly improved
functionality over XHTML 2.0, ie, something that could be held up and
recognised as a major contribution to the evolving library of XML based
document schema languages; and

(b) we can do so at reasonable cost to the TC and its members (we will be
competing with XHTML 2.0 in the marketplace);

I think also that it would be convenient to have a simple, stable model to
represent our standard, even if the underlying clause model is later
supplanted by XHTML 2.0 or something else. In the circumstance, this is only
desirable if it can be achieved without interfering with the other work of
the TC.

If we can't meet these objectives, I doubt that it is a good use of member
resources to develop a new model.


2. OVERVIEW OF XHTML 2.0 MODEL

This overview highlights only a few key points that correspond to issues
that have arisen during clause model development. It is not a complete
review of the XHTML 2.0 proposal.

The proposed XHTML 2.0 model has these key features:

(a) a <section> element, with optional heading <h> that can be used
recursively to create the document outline;

(b) a <p> container with an <l> element that is broadly similar to the
block/para and Text grammatical paragraph proposed for the grammatical
paragraph model;

(c) discrete list types for different types of list, as in HTML & XHTML 1.0;
and

(d) it uses a separate <li> element for items in lists.

In terms of points (a) and (b), the XHTML 2.0 proposal is very similar to
the grammatical paragraph model.

In terms of points (c) & (d), I believe the XHTML 2.0 model is quite
inferior. Using elements to define list numbering is redundant and
unnecessarily complex. Using a discrete list item element limits
re-usability. Overall, the model creates a separation between the document
outline and the narrative content that is inconvenient.

Notwithstanding I would like to see a simpler and more flexible model, I
have no doubt that if XHTML 2.0 is supported by applications, it could be
widely used. It should be capable of adaptation to a wide range of
situations.


3. COMMENTS ON JASON'S SIMPLE PARAGRAPH MODEL (17 November 2003)

3.1 Overview of the issues

My reading of Jason's proposal is that it seeks to:

(a) completely eliminate author decision making in the use of clause -
subclause - list markup, except in regard to the applied numbering scheme;

(b) maximise re-usability of content at any level in the document hierarchy;
and

(c) support inline lists.

I accept that it achieves these objectives. However, I wonder about the
nature of the problems it was trying to overcome, compared to the
grammatical paragraph model submitted earlier.

The countervailing effect of Jason's simple paragraph model is to:

(a) remove the grammatical paragraph container (block or para); and

(b) create a very loose model for the document outline based on interspersed
Items and Text elements at any level of the document:
<!ELEMENT Item (Num?, Heading?, (Items | Text)*)>

3.2 Author convenience & reusability

In the grammatical paragraph model, author decision making is limited to
placing an item inside or outside a block/para element. Authors would only
need to actually consider this infrequently. Default application behaviour
would take care of the rest. The choice to be made is far simpler than with
almost any other available DTD, including XHTML 2.0. Consequently, I believe
that Jason has taken a very strong magnifying lens to this issue.

In the grammatical paragraph model, re-usability was slightly impaired in
only one extreme case. That is if the application uses XML or RELAX NG
schema to redefine item when contained by block/para. In this case, an item
containing another item directly could not be moved from the outline to the
narrative. In practice, I believe this is a very extreme case. Again, I
think that Jason has taken a strong magnifier to this issue.

3.3 Inline lists

Jason proposes that inline lists should be created by allowing Items to
occur inside Text:
<!ELEMENT Text (#PCDATA | Items)*>

To switch between the two formats for lists (inline or new line), the list
has to be moved in our out of the Text container. It seems likely that to
avoid this problem, the two forms could be easily corrupted in use so that
some applications would convert standard lists into inline presentation by
adding an attribute to the list container while others may make lists in the
Text new line in a similar way.

I would expect authors who create inline lists to perform many more inline -
new line transformations of lists than choices between items in the document
outline or narrative to achieve particular numbering outcomes. For reasons
which are unclear, Jason seems far more concerned about later issue than the
former.


3.4 The grammatical paragraph
I believe that loss of the grammatical paragraph container would be very
unfortunate. It is possible to live without it in many situations but why
should we have to abandon it?

It will make it harder for authors to easily and consistently represent
grammatical paragraph structures where they are desired. It is only part of
the problem to tie two Text elements together using attributes. Whether
narrative lists and other structures are tied to preceding text will be an
open question. Authors will fail to apply markup because applying attributes
is rarely very convenient. The absence of a container prevents easy re-use
of block/para objects as discrete components.

Based on experience, I believe that many people will want to re-use
block/para objects. That XHTML 2.0 is now adopting a grammatical paragraph
model appears to support the view that there is a wider need.

It will be difficult to reliably convert data from the simple paragraph
model to the grammatical paragraph model. Often, the required structural
information will be absent.


3.5 The document outline

Jason acknowledges this issue under "Titles on Items in the document
outline" but dismisses it as "hardly a fatal flaw".
I beg to differ. There are actually 2 problems to address:

(a) Users can create irregular hierarchies with mixed paragraphs and items;

(b) What is the boundary between items included in the contents listing and
those not included?

I believe this is the most significant limitation with the proposed simple
paragraph model. The basic issues were canvassed in the grammatical
paragraph model on 11 November 2003, topics 9.5.2 and 10.6. These issues
will affect almost every user of the model at some time. The simple
paragraph model provides no means to enable users to apply tighter or looser
models to deal with problem (a). A tight model cannot be used, even with XML
and RELAX NG Schema. Because there is no alternative element context (Items
always occur in context of Item), neither schema language allows the content
model to be re-defined.

Users are stuck with a model even looser than the loose model suggested in
the grammatical paragraph model proposal. Authors will be able to create
unconstrained jumbles of objects. Based on experience, this will make it
difficult for many enterprises to achieve consistent data to support
publishing and processing needs. It is a major limitation with the model.

The options regarding problem (b) are essentially the same as for Option 1
in topic 10.6 of the grammatical paragraph proposal. It seems that Option 3
is not even available with RELAX NG schema.

3.6 Conclusions regarding the simple paragraph model
I believe the proposal lacks balance. It is selective in the issues it seeks
to address. It overstates the problems of the grammatical paragraph model
regarding ease of use and re-usability and overstates the benefits of the
model in these areas.

On the other hand, it understates the problems regarding the grammatical
paragraph and the document outline and cannot provide any flexibility to
meet likely user needs in these areas. It is a proposal of extremes that
fails to recognise that, to be successful, the model must be capable of
meeting a wide range of needs.

I believe there is no prospect that the simple paragraph model would gain
the sort of widespread acceptance that would justify its adoption,
regardless of the presence of XHTML 2.0. Some users may find it adequate but
it would be just another niche schema.


4. OTHER OPTIONS

4.1 Grammatical paragraph model and inline lists

As stated in topics 11.6 and 11.7, a final decision on whether to include a
List (Items) element in that model was substantially dependent on the
requirements for inline lists.

I assume the following requirements:

1. Despite likely haphazard use of markup for inline lists, there is a need
for markup that allows authors to create list structures that can be
rendered inline.

2. If marked up, inline lists need automatic numbering.

3. Authors would like to be able to conveniently switch between inline and
new line list display. Consequently, it is desirable to use the same markup,
even if the item may contain block content.

4. Multiple inline lists can exist within a single paragraph.

5. It seems possible to have an inline list and a new line list within the
same paragraph.

6. It seems that authors may want multiple inline lists within a paragraph
and use different numbering for each.

If these are to be met using the grammatical paragraph model, a list
container would be highly desirable to enclose inline or new line lists in
the narrative:

<!ELEMENT Block (Text | List)*>

Depending on the approach taken, the following also may be needed:

<!ELEMENT Text (#PCDATA | List)*>

Under the grammatical paragraph model, a list container in element Block
retains the problem that lists can be created in multiple ways. DTD users
cannot avoid this problem but Schema users can overcome it at the cost of
limiting the ability of users to move directly nested Item elements from the
document outline to the narrative. In my view this is an inconsequential
cost.

More significantly, the List container complicates re-designation of Items
between the outline and the narrative because it involves two operations,
rather than one.

If the List container is to be introduced, it could be done in two ways:

Option 1 - Allow List in the Text context
This is similar to the approach suggested by Jason in the simple paragraph
model. In the context of the grammatical paragraph model it means that
authors use the same technique (drag an object into or out of a container)
to change list display as for moving Items between the document outline and
the narrative.

Option 2 - Use a display attribute on the List container

Alternatively, an attribute could be used on the list element to determine
whether the list is rendered on a new line or in line. Something along the
lines of:

<!ELEMENT Block (Text | List)*>
<!ELEMENT List (Item+)>
<!ATTLIST List  display   (inline)  #IMPLIED >   [The default treatment
would be to render on a new line.]

Under this approach, a Text element immediately after the list might be
rendered inline if the list is inline. Switching from inline to new line
would merely involve changing the attribute.

Some might think this is more convenient for this more common operation,
depending on the user interface provided. I do not have a strong preference
either way at this time.

Once the List element is added to the grammatical paragraph model, it is one
step closer to XHTML 2.0.

4.2 Combined model

It would be possible to combine the grammatical paragraph with Jason's
proposal along the following lines:

<!ELEMENT Items (Item*)>
<!ATTLIST Items  render   (inline)  #IMPLIED >
<!ELEMENT Item (Block* | Items)>  [Tight model]
<!ELEMENT Block (Text | Items)*>
<!ELEMENT Text (#PCDATA)>

Fundamentally, this is very similar to the grammatical paragraph model but
the Items element in the document outline is redundant. I have not
identified any advantages in this approach. If some are suggested, the
option could be explored further.


5. CONCLUSIONS

5.1 Direct comparison
My perspective is that the simple paragraph model is not a good compromise
for dealing with the range of objectives for the clause model. It does some
things very well and others very poorly.

Compared to XHTML 2.0, it provides greater re-usability and simplicity for
authors for some operations. However, it cannot reliably support
transformation to the grammatical paragraph model proposed in XHTML 2.0.
This is a serious shortcoming.

XHTML 2.0 would allow the content model for <section> and <p> to be
redefined as loose or tight, according to user needs. The tight models would
remain compatible with the base standard. The simple paragraph model appears
to exclude the ability to tighten the model using any available schema. This
is its major shortcoming, from my perspective.

The grammatical paragraph model can be adapted to include a List element (or
other name) if necessary to provide for inline lists.

The grammatical paragraph proposal is significantly more flexible and allows
users to more accurately model their desired data in the document outline
and in the narrative. I consider that it is a less extreme compromise and
provides a better overall fit to the requirements.

Compared to XHTML 2.0, the grammatical paragraph model offers a simpler and
more flexible representation of narrative lists and greater re-usability
that, practically, is hardly distinguishable from the simple paragraph
model.

5.2 Should either model be adopted?

I believe our further work will have to support XHTML 2.0, whatever we
decide on a separate clause model. We will have to learn to adapt it to
contract user needs.

I believe that the simple paragraph model does not satisfy the criteria I
have proposed for adoption. It is too narrow in its features for the job
required. Its benefits over XHTML 2.0 are more than outweighed by its
limitations.

The grammatical paragraph model offers some benefits over XHTML 2.0 with
fewer downsides. However, it is not clear that these are sufficient to
justify the work in developing an alternative model. If there was unanimity
in our approach and the load could be shared, I think it could be worth
proceeding. Much of the extra work has to be done whichever way we go.
However, I doubt very much it is worthwhile if the process is seriously
contested within the TC.

My personal view is that we should try to determine the general views of TC
members to see what preferences emerge. Possible questions would be:

1. In the light of the XHTML 2.0 draft, do we still see any merit in
proceeding with a separate clause model development?

2. If no, do we now work exclusively with draft XHTML 2.0?

3. If yes, do we want to start with the grammatical paragraph model, the
simple clause model or something else as a basis for the further
development?

4. If yes to 1, do we want to undertake further work in parallel on a new
clause model and XHTML 2.0?


Regards
Peter Meyer