Re: [oXygen-user] Strange Results from XSD Documentation Generator
Thank you for the files. I logged the two bugs in our internal system for a future version of oXygen. Regards, Sorin Eliot Kimber wrote:
Sorin Ristache wrote:
Hello,
Please provide the XSD file. It looks like a bug in the code for generating the schema documentation.
Failing XSD is attached.
If you go to the entry for frb_publication you should see that most of the boxes in the model picture are not working links, but "index" is.
If you go to something like "p" you'll see that all the links from the model picture are good but all the links from the instance representation and XSD markup are like this:
<div style="margin-left: 1.5em"><<span class="scTag">xsd:element</span> <span class="scTag">ref</span>="<span class="scContent"> <a title=""q" element declaration could not be found." href="javascript:void(0)" onclick="alert('"q" element declaration could not be found.');">q</a> </span>"/></div>
The XSD is generated from a local DITA specialization shell using the NekoDTD parser.
Sorin Ristache wrote:
Thank you for the files. I logged the two bugs in our internal system for a future version of oXygen.
Is there any workaround for the bugs? Since I"m generating the XSDs I could possibly do whatever is needed to avoid the problem. Thanks, Eliot -- Eliot Kimber Senior Solutions Architect "Bringing Strategy, Content, and Technology Together" Main: 610.631.6770 www.reallysi.com www.rsuitecms.com
I am sorry, we do not have workarounds for the two reported problems. All the textual links are not generated correctly. Also the links corresponding to references used inside an xs:choice which is used inside an xs:sequence are not generated correctly. If you can avoid references used inside an xs:choice which is used inside an xs:sequence you can avoid the second bug. You say the XSD is generated automatically from a DTD which is a DITA specialization using the NekoDTD parser so I assume you cannot control the format of the final XSD output. Regards, Sorin Eliot Kimber wrote:
Is there any workaround for the bugs? Since I"m generating the XSDs I could possibly do whatever is needed to avoid the problem.
Thanks,
Eliot
We found a workaround for the broken links in the XML Instance Representation sections: add the attribute targetNamespace="" to the xsd:schema root element of your schema which has no namespace. There are some matches in the modified xs3p.xsl stylesheet of oXygen that fail for schema components that do not have a namespace prefix but adding this attribute is a workaround. Regards, Sorin Eliot Kimber wrote:
Is there any workaround for the bugs? Since I"m generating the XSDs I could possibly do whatever is needed to avoid the problem.
Thanks,
Eliot
participants (2)
-
Eliot Kimber -
Sorin Ristache