Oleg Tkachenko wrote:
The FO spec is clear that the content is a sequence group. However, semantically, there's no point in constraining the order of occurrence in this case as there is no interdependenc of the elements. I'm sure that if XML had AND connectors the editors would have used them. Since there can be no practical failure that would result from a different order of region declarations, I think it's appropriate to not enforce the content model.Peter B. West wrote:I have debugging my FO tree building be running it against various example fo files. Of the three I have used so far, I have found problems with two.Hmmm, allregions.fo looks okay to me. Probably this stuff is also in tables/background.fo, this one really have
./docs/examples/pagination/allregions.fo has the problem that I mentioned in an earlier past; the simple-page-master does not have region-body as the first region specified.
btw, neither antenna nor XEP don't complain on it.
In fact, I did a quick survey of all the formatting objects and this is the only case in which a sequence group is used where the order does not have some obvious purpose (e.g., putting declarations before uses).
While any implementation would be free to complain if the order were not followed, I would consider that to be a "Simon Says" behavior--that is, complaining about something that could either be recovered from without risk or that cannot possibly hurt anything in the first place. I'm not sure how culturally distributed the childs' game of Simon Says is, but the basic idea is that one child gives orders and the other performs them IFF the first child says "Simon Says", as in "Simon says touch your nose" or "touch your nose" (if the orderee complies, the first child says iperiously "I didn't say Simon Says") (at least I think that's how it's played--it's been a long time since I played it and I have no children at hand to remind me of the details). In any case, I consider Simon Says behavior to be one of the more heinous sins of software implementation. It's especially prevelant in the implementation of standards, as one might expect.
On the other hand, unrestrained recovery and fallback can lead to its own problems, as we learned from HTML. For example, I've found XSL Formatter's almost total lack of validation of FO instances to be counter productive in the long run if one is not checking their FO markup, either with XEP or by inspection against the spec. Fortunately, RenderX provides their validator as service to the community, so there's no excuse for anyone producing FO instances that don't at least conform to the rules XEP validates.
W. Eliot Kimber, [EMAIL PROTECTED]
Consultant, ISOGEN International
1016 La Posada Dr., Suite 240
Austin, TX 78752 Phone: 512.656.4139
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]