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... :-)
Regards,
Arved Sandstrom
Fairly Senior Software Type
e-plicity (http://www.e-plicity.com)
Wireless * B2B * J2EE * XML --- Halifax, Nova Scotia
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
