Say we have an FO schema (possibly converted from that fo.dtd) and from that we remove what FOP doesn't do yet. Then we can easily compare both schemas with XSLT and generate a nice report. (I would volunteer to try and write that XSLT/report if people think it can be useful).
Then we can add comments or annotations to tell about workarounds and about what is implemented BUT still is not working as expected. However, I suppose it would be a lot of work to remove unimplemented things from fo.dtd or fo.xsd. What do you think? Benoit -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, March 21, 2002 1:33 PM To: [EMAIL PROTECTED] Subject: RE: feature and limitation lists Hello, Markus wrote: > If you have any suggestions about how to do this easily then > share your ideas with us. I've suggested (or asked) to create a special fop.dtd (not a fo.dtd). This wouldn't regard all limitation and no workarounds, but it would be a very good tool for imlementing applications using FOP. E.g.: fo.dtd" (I know that there's no official fo.dtd, I took the one created by Nikolai Grigoriev <[EMAIL PROTECTED]>): ---------8X----------------8X----------- <!ENTITY % area-properties " clip CDATA #IMPLIED [..] "> [ ... block-properties is an entity based (indirectly) on area-properties ... ] <!ELEMENT fo:block (#PCDATA | fo:initial-property-set | %basic-inlines; | %basic-blocks; | %out-of-lines; | %wrappers;)*> <!ATTLIST fo:block %block-properties; > ---------8X----------------8X----------- FOP.dtd: ---------8X----------------8X----------- <!ENTITY % area-properties " <!-- clip CDATA #IMPLIED not implemented by FOP yet ---> [..] "> [ ... block-properties is an entity based (indirectly) on area-properties ... ] <!ELEMENT fo:block (#PCDATA | fo:initial-property-set | %basic-inlines; | %basic-blocks; | %out-of-lines; | %wrappers;)*> <!ATTLIST fo:block %block-properties; > ---------8X----------------8X----------- I don't know how FOP is implementing these features, maybe it would be easier to remove these entities and list all attributes and content elements explicit. But maybe these entities represent the internal implementation structure... A fop.dtd will answer all these question like: Feature XYZ is not working, is it a bug in my FO document or a missing FOP feature. Maybe workarounds can be mentioned in the fop.dtd, too. Since fo.dtd exists, it wouldn't be too much work to add these comments. Regards, Jens
