Re: FO DTD from XSL WD.

>> Do I understand right that any inheritable attribute,
>> may appear within *any* element in FO stream?


>FOP treats it that way. Another way would be to only allow inheritable
>attributes on elements whose allowable decendants can use that attribute.


Unfortunately, I'm trying to understand what is the way
proposed by WD. FOP's behavior may be right, but
behavior of another rendering engine may be
"another way" - as a result  if somebody is rendering
some FO with FOP - it may result in producing invalid
FO's  ( that would be considered invalid ) by another
software.

I hope the purpose of WD (or any other stantard)
is to *avoid* such problems. Isn't it?

>> If no - is there any way to understand what
>> attribute is valid for some element? Usualy we are
>> using ATTLIST to explain such relations, right?
>
>Yes. But you are supposing that there is value in a notion of validity that
>is contraining enough to rule out attributes that won't be used. I don't
>necessarily disagree with you, but it is worth noting that it is a design
>decision whenever developing schemata (and I always include DTDs when I say
>'schemata') which constraints are in the schema and which you check at the
>application level. Some schema languages can express more than others. For
>example, a FO DTD couldn't constrain the values of "font-size" to those the
>prose of XSL WD does. The new W3C XML Schema language will be able to in
>this particular example.


I understand this point, but unfortunately I don't
see too much relation.  Yes, one should use CDATA
for any attribute. It's OK. The WD provides
all the materials you need to validate the
value of font-size. It seems that  WD provides you
with no information about what is the relation
between elements and their attributes and this is
*very* strange.

>> For some reason XSL WD is not using DTD for
>> that ordinary and trivial purpose, but is using DTD
>> syntax for some other purpose.
>
>A useful purpose, though. One that is aimed more at implementors than
>stylesheet writers. Of course, it would be perfectly possible to have a DTD
>for both, still bearing in mind that there will be a lot of constraints
>*not* expressed in the DTD.


Unfortunately in this case we have a situation when constrains
are not expressed *at all*, not only in the DTD.

Rgds.Paul.

 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
       Email: paul@xxxxxxx  http://www.pault.com
  PerlApplicationServer | XMLTube | Perl/JavaConnector
 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=




 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list