[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: Categorized element list
/ "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 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC