/ Eve L. Maler <> 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 <>
Life always comes to a bad Principal Software Engineer
end.--Marcel Aym'e Arbortext, Inc. (www.arbortext.com)
413.256.6985 Voice/FAX
