RE: feature and limitation lists
Here are some early results. All elements are listed, but only unimplemented attributes child elements are shown within the elements. Attributes values are not checked yet; additional comments regarding partial implementation are not there yet neither. Obviously it needs some clean-up, but I will probably not continue until 1-2 weeks from now (holidays :-). As Chuck wrote, it is not 100% correct. I noticed white-space- and linefeed-treatment are claimed implemented, though I thought they were not yet. Also, I think that fo:float is not implemented neither. But I didn't check, maybe it is in 0.20.3. This is just a proof of concept, so I don't care too much about accuracy just yet. I did it using Chuck's DTD, not schema: I wrote a small XSLT that walks through FO.dtd (converted to xsd) and checks if corresponding element/attribute exists in FOP.dtd (xsd). (Actually, this generates an XML file looking like a XSchema, which is then converted to HTML.) Chuck: a question about your xsd file: you grouped the attribute types into xs:simpleType elements. But are we sure that a given attribute is always implemented the same way in all elements that has it? Comments welcome. Benoit P.S. For the record, I am not doing this on behalf of Eurocontrol, despite me using that email address. -Original Message- From: MAISONNY Benoit [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 02, 2002 12:05 PM To: '[EMAIL PROTECTED]' Subject: RE: feature and limitation lists Thanks for your 2 emails (that I couldn't read until today, sorry). As I wrote earlier, I will investigate how to automatically generate unimplemented features documentation. Benoit -Original Message- From: Chuck Paussa [mailto:[EMAIL PROTECTED] Sent: Monday, March 25, 2002 6:42 PM To: [EMAIL PROTECTED] Subject: Re: feature and limitation lists Here's an FOP specific xsd. I sent the segregated DTD in a previous response on this same thread. It's a pain to make a usable XSD from a DTD because the conversion tools tend to explode everything out and you get enormous repeating elements. Anyway. Here it is for what it's worth. Chuck Paussa MAISONNY Benoit wrote: 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]): -8X8X--- !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; -8X8X--- FOP.dtd: -8X8X--- !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; -8X8X--- 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 Title: Features not yet implemented in FOP
RE: feature and limitation lists
Hi, -Original Message- From: Fries, Markus, fiscus GmbH, Bonn [mailto:[EMAIL PROTECTED] [...] I think these should be added as well for fop-0.20.3-2002-03-04: not implemented yet: fo:block visibility=hidden page-position=last Anyway, attribute values are not yet considered in my XSLT. I'll do it later. But what about wrong implementations? Example: markers, or wrap-option=wrap This works fine, if spaces are existing. But it should wrap long lines with no spaces at the boundaries as well. It would make sense to add javadoc like comments to the dtd's or xsd's. You did not publish your small xslt yet? As I wrote, I plan to it later as well. I've done exactly this already for another XSchema: I have an external annotations XML file, instead of having the annotations inside the XSchema as it is usually). Annotations are then merged into the HTML doc. I will publish my small XSLT when it is more complete. This was just a quick-and-dirty feasibility test. Benoit Regards Markus Fries -Ursprüngliche Nachricht- Von: MAISONNY Benoit [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 9. April 2002 11:33 An: '[EMAIL PROTECTED]' Betreff: RE: feature and limitation lists Here are some early results. All elements are listed, but only unimplemented attributes child elements are shown within the elements. Attributes values are not checked yet; additional comments regarding partial implementation are not there yet neither. Obviously it needs some clean-up, but I will probably not continue until 1-2 weeks from now (holidays :-). As Chuck wrote, it is not 100% correct. I noticed white-space- and linefeed-treatment are claimed implemented, though I thought they were not yet. Also, I think that fo:float is not implemented neither. But I didn't check, maybe it is in 0.20.3. This is just a proof of concept, so I don't care too much about accuracy just yet. I did it using Chuck's DTD, not schema: I wrote a small XSLT that walks through FO.dtd (converted to xsd) and checks if corresponding element/attribute exists in FOP.dtd (xsd). (Actually, this generates an XML file looking like a XSchema, which is then converted to HTML.) Chuck: a question about your xsd file: you grouped the attribute types into xs:simpleType elements. But are we sure that a given attribute is always implemented the same way in all elements that has it? Comments welcome. Benoit P.S. For the record, I am not doing this on behalf of Eurocontrol, despite me using that email address. -Original Message- From: MAISONNY Benoit [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 02, 2002 12:05 PM To: '[EMAIL PROTECTED]' Subject: RE: feature and limitation lists Thanks for your 2 emails (that I couldn't read until today, sorry). As I wrote earlier, I will investigate how to automatically generate unimplemented features documentation. Benoit -Original Message- From: Chuck Paussa [mailto:[EMAIL PROTECTED] Sent: Monday, March 25, 2002 6:42 PM To: [EMAIL PROTECTED] Subject: Re: feature and limitation lists Here's an FOP specific xsd. I sent the segregated DTD in a previous response on this same thread. It's a pain to make a usable XSD from a DTD because the conversion tools tend to explode everything out and you get enormous repeating elements. Anyway. Here it is for what it's worth. Chuck Paussa MAISONNY Benoit wrote: 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]): -8X8X--- !ENTITY % area-properties clip CDATA #IMPLIED [..] [ ... block-properties is an entity based
RE: feature and limitation lists
Thanks for your 2 emails (that I couldn't read until today, sorry). As I wrote earlier, I will investigate how to automatically generate unimplemented features documentation. Benoit -Original Message- From: Chuck Paussa [mailto:[EMAIL PROTECTED] Sent: Monday, March 25, 2002 6:42 PM To: [EMAIL PROTECTED] Subject: Re: feature and limitation lists Here's an FOP specific xsd. I sent the segregated DTD in a previous response on this same thread. It's a pain to make a usable XSD from a DTD because the conversion tools tend to explode everything out and you get enormous repeating elements. Anyway. Here it is for what it's worth. Chuck Paussa MAISONNY Benoit wrote: 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]): -8X8X--- !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; -8X8X--- FOP.dtd: -8X8X--- !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; -8X8X--- 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
Re: feature and limitation lists
Here's an FOP specific xsd. I sent the segregated DTD in a previous response on this same thread. It's a pain to make a usable XSD from a DTD because the conversion tools tend to explode everything out and you get enormous repeating elements. Anyway. Here it is for what it's worth. Chuck Paussa MAISONNY Benoit wrote: 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]): -8X8X--- !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; -8X8X--- FOP.dtd: -8X8X--- !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; -8X8X--- 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 attachment: fop4da.zip
RE: feature and limitation lists
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]): -8X8X--- !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; -8X8X--- FOP.dtd: -8X8X--- !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; -8X8X--- 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
RE: feature and limitation lists
Title: RE: feature and limitation lists Hello, Yes, I think this would be very helpful. But it has one drawback though. You realize only after implementing that s.th. doesn't work and expensive rework is necessary. If you have a nice editor, you can use the DTD resp. XSchema while editing. Benoit suggested to use an XSchema instead of a DTD for enabling nice reports. So I change my suggestion: fop.xsd instead of fop.dtd (and fo.xsd instead of fo.dtd) ;-) Regards, Jens
