Robert D Anderson wrote:
> The spec shows that p is contained by itemgroup, and that itemgroup
> contains p, but not the other way around. Is this a request to allow
> itemgroup within <p>?
Yes, I must have misread something before, but in implementing my
specialization I did discover that itemgroup is not allowed within <p>
and confirmed that that's what the spec says.
So this is worse than I thought, in that there is *no* way to do the
specialization I need.
I see this as a bug in that as currently defined there is no way to
directly bind <data> to subelements of <p> that are not also allowed in
<ph>. Since you can bind <data> to *some* children of <p> the fact that
you can't do it for *any* seems like a bug (that is, what is allowed for
some should be allowed for all).
I'm not sure what the most appropriate solution is, as I can see several
alternatives that would allow the specialization pattern I need:
1. Allow everything allowed by <p> in <ph>
2. Allow itemgroup w/in <p> (and allow itemgroup to nest)
3. Define a new wrapper base type analogous to itemgroup but more generic.
Relaxing the content model of <ph> would be the easiest to implement but
might surprise tools that currently don't expect figures within phrases
(although it really shouldn't matter).
Allowing itemgroup w/in <p> would be easy to implement and would
probably not be as disruptive.
A new wrapper type is probably the cleanest solution but would be the
hardest to implement.
Cheers,
E.
--
W. Eliot Kimber
Professional Services
Innodata Isogen
8500 N. Mopac, Suite 402
Austin, TX 78759
(214) 954-5198
www.innodata-isogen.com
