A few quick thoughts...
That was probably just my XML super-ego thinking that case-by-case
checks were a _bad_ thing... But on the other hand, as Arved points out,
the complexity of the model would make it rather problematic. It's
certainly more important to focus on detecting cases which FOP (or FO)
can't or isn't supposed to handle and giving some kind of comprehensible
message to the user, rather than getting hung up on formal correctness.
We can do some global checking in the "end" method if that's necessary.
That lets us look at all the descendants of an FO. The other way to look
at constraints like the footnote one (or more generally, no floats
beneath other floats - Dieu merci!) is from the ancestor point of view.
When an FO is created, it knows what its parent will be even though it
isn't yet on that parent's child list. So a footnote or float FO can
check to see if has a footnote or float ancestor.
We also need to think about what to do when we encounter this kind of
case. Obviously we want to inform the user. We could either stop on an
exception or just ignore the offending FO and keep going.
Considering the property validity checks, I haven't touched that stuff
in ages. In general there are warning messages for values that aren't
convertible into one of the expected types. Most properties are just
assumed to be valid for all elements unless they are explicitly
associated with a particular element or elements.
There are still lots of values which aren't handled, including the
famous "inherit" keyword for all properties. In short, there is still
plenty of work in there for some enterprising person(s).
Regards,
Karen
Arved Sandstrom wrote:
>
> At 10:25 PM 7/11/01 +0200, Karen Lease wrote:
> >Keiron Liddle wrote:
> >....
> >> Then after that I will see about handling the element child constraints (I
> >> haven't worked out how this should be done yet, any ideas) and doing a
> >> similar thing (to be impl.) with the rest of the elements that we don't
> >> have yet.
> >>
> >
> >For things like tables, I had been thinking of handling child type
> >checking in the addChild method. That way we can give messages early in
> >the game and also do special things like handling different children in
> >special ways. An example is when table-cell FO are directly under a
> >table-body (or header or footer) rather than in a table-row. In that
> >case, I think it would be better to create a "fake" row to hold them.
> >That kind of work is logically done during FO tree building.
> >
> >However that's rather a piecemeal approach. Perhaps it would be good to
> >describe (schema? DTD?) the possible child types and have the base class
> >implementation do that kind of checking.
> >
> >Just my .02 euros!
>
> I wonder if we should bother with formal parse-time validation at all (i.e.
> the schema/DTD idea). We already know that inheritable properties complicate
> the attribute issue, and then we also know that there are enough formatting
> objects with special content constraints that why even bother?
>
> I suggest letting the existing (and improved as required) properties
> refinement mechanism worry about checking property validity (Karen, maybe
> you can give us a state of the union as to where we stand on this?), and as
> Karen also mentioned, let's build in our own checking mechanism. My
> contribution to Karen's comments is merely to argue for not even bothering
> with schemas or DTDs at all.
>
> Perhaps we should winnow out all the rules from the spec into one document,
> and that should give us a 10,000 ft view of what we are faced with. That
> might lead us to an efficient approach, or suggest certain base-class
> checking shortcuts rather than sub-class checking. For example, among the
> variety of things we have are:
>
> 1) fo:wrapper -
> (#PCDATA|%inline;|%block;)*
> An fo:wrapper is only permitted to have children that would be permitted to
> be children of the parent of
> the fo:wrapper, with two exceptions:
> * An fo:wrapper may always have a sequence of zero or more fo:markers as its
> initial children.
> * An fo:wrapper that is a child of an fo:multi-properties is only permitted
> to have children that would
> be permitted in place of the fo:multi-properties.
> This restriction applies recursively.
>
> 2) fo:footnote
> Contents:
> (inline,footnote-body)
> An fo:footnote is not permitted to have an fo:float, fo:footnote, or
> fo:marker as a descendant.
> Additionally, an fo:footnote is not permitted to have as a descendant an
> fo:block-container that
> generates an absolutely positioned area.
>
> 3) fo:table-header
> Contents:
> (table-row+|table-cell+)
> The fo:table-header has fo:table-row (one or more) as its children, or
> alternatively fo:table-cell (one or
> more). In the latter case cells are grouped into rows using the starts-row
> and ends-row properties.
> In addition this formatting object may have a sequence of zero or more
> fo:markers as its initial children.
>
> I do not get the feeling that we have a comprehensive or consistent system
> for enforcing these content rules. Note the fo:footnote constraint?
> _Descendant_ constraint, not just child? Makes things interesting... :-)
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
