Re: Categorized element list

[Norman Walsh <nwalsh@arbortext.com>]

/ "Eve L. Maler" <elm@east.sun.com> was heard to say:
| I'm really psyched to hear about the work done at last week's meeting.  I 
| did notice that there are "semantic" groupings such as informal objects 
| next to "formatting" groupings such as verbatim; I bet most of the verbatim 
| elements would more usefully go into a semantic grouping.

Agreed. I think we need purely semantic groupings.

| You could use this test: "Among which elements would I want to choose when 
| faced with a piece of information that needs marking up?"  E.g., when 
| trying to insert a code example into a document, you might decide you want 
| example, informalexample, programlisting, screen, or even screenshot or 
| synopsis!

I phrased the question differently (though I failed to use it to
discriminate when I made the non-semantic groupings :-), "how
would I group elements such that in any situation where I might
reasonably select one element of the group, it would be
unreasonable to prohibit any other member of the group from
appearing?"

For this reason, I would not put programlisting and synopsis in
the same group, although I can imagine that most content models
that included the "verbatim" group would also include the
"synopsis" group. In "verbatim", address is clearly the
outsider.

|  We might not want to mix formal and informal objects into the 
| same class because we want to restrict where titled things can appear, but 
| this exercise can be handy (and it's better to make fine class distinctions 
| than gross ones because you can add a bunch of classes to any one mixture).

Exactly. I also observe that now that we have PEs around every
element and attribute declaration individually, it's perhaps
less important to make every content model rely only on PEs.
(Because it's so much easier for customizers to selectively change
individual elements or groups of elements.)

| You'll need to ensure eventually that elements don't appear in more than 
| one group.  It gets hard to avoid content model ambiguity when the same 
| element appears in multiple class entities.

Yep. That's the '*' in my list. Looking at the problematic elements,
I see that 

- the productname and productnumber overlap could be removed by allowing
  trademark in meta, which seems reasonable. We allow copyright.

- revhistory is problematic because it accidentally slipped out of meta,
  which is the only place I think we planned to put it. But now we have
  users taking advantage of this, and it's not unreasonable, so we're
  stuck.

  But the meta-PE and the non-meta-PE are never going to overlap in
  the same content model, so it's probably OK to have revhistory in
  both.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <nwalsh@arbortext.com> | Life always comes to a bad
Principal Software Engineer         | end.--Marcel Aym\'e
Arbortext, Inc. (www.arbortext.com) | 
413.256.6985 Voice/FAX              |