From: Nikolai Grigoriev (grig@renderx.com)
Date: Tue Nov 05 2002 - 03:04:24 PST
Hi Eliot,
> > Looks like the attlist for fo:table should be using %table-properties;
> > but it's using %block-properties; (cut and paste error from
> > fo:table-and-caption?).
>
> Wrong fix: fo:table should use %inheritable-properties;, not
> %block-properties;, I think. But now I'm confused. The inheritance stuff
> in FO doesn't really play well with DTD attribute declaration syntax.
%block-properties are composed of %inheritable-properties and @id,
and it is exactly what I meant to appear on fo:table. (They comprise
%table-properties through %inheritable-properties). Note that
%inheritable-properties is a collection of all attributes that accept
expressions: it includes virtually all properties except for @id, @ref-id
and the likes. (Maybe the entity name is a bit misleading).
Unfortunately, you cannot restrict properties of a table any more.
In XSL FO, the attribute structure is completely decoupled from the
element backbone. Property-value functions make it legal to
specify _any attribute_ on any ancestor element, even on fo:root -
"from-nearest-specified-value()" can always take it from there.
This is not a problem of DTD, but rather an inherent weakness
of XSL FO language itself that cannot be repaired with a schema
language. You know, in XEP 3 we use Schematron-like, XSLT-based
validation: many deficiencies of the DTD could be compensated
but not this one.
The best thing we can do in a DTD is to restrict attribute sets
on empty elements: they have no descendants, and thus need
not bear but attributes directly consumed by the element.
But even this, I wonder if it is conformant to the Recommendation:
if spurious attributes are tolerated on fo:block, why should
we ban them on fo:external-image?
Best regards,
Nikolai Grigoriev
-------------------
By using the Service, you expressly agree to these Terms of Service http://www.renderx.com/tos.html
This archive was generated by hypermail 2.1.5 : Wed Dec 18 2002 - 08:41:28 PST