Community
Participate
Working Groups
I20070208-0010 Generated schema description is not valid HTML. E.g. validating the schema description for org.eclipse.ui.workbench.texteditor.hyperlinkDetectors yields 48 errors. Most of them are duplicate id=... attributes and nested <p> tags. The nested <p> tags are especially bad, since they make copy-paste of examples unusable, e.g.: <extension point= "org.eclipse.ui.workbench.texteditor.hyperlinkDetectorTargets" > <target id= "org.eclipse.jdt.ui.javaCode" name= "Java Editor" > <context type= "org.eclipse.ui.texteditor.ITextEditor" /> </target> </extension>
This would be a high impact bugday contribution, since all HTML documents generated for all extension points in the world go through this piece of code.
Look at SchemaTransformer in pde.core I'm attaching a mylyn context to help people out also.
Created attachment 77321 [details] mylyn/context/zip
This is a nice one to fix Adam.
Created attachment 77896 [details] patch With this patch, all of the validation issues (that I could find) are resolved. There are, however, some complications. The duplicate ids mentioned in comment 0 were actually being used to specify the CSS class to be used. This means that removing the duplicate ids also meant modifying the schema.css so that the classes do not depend on the element id. Unfortunately, updating the css does not seem to be as trivial as one would have hoped. At first, the change just did not seem to be taking effect. I then discovered that o.e.pde.core is caching its schema.css in the workspace's .metadata. When I replaced the schema in there with my changes, everything worked as desired. After that, I noticed that PDE is first asking for the schema from o.e.platform.doc.isv and then only getting the one from pde.core if the docs didn't supply one for whatever reason. When I updated the schema.css in doc.isv, and ran on an old workspace (with the new pde.core and doc.isv in my workspace), it picked up those changes. What I'm unsure about, at this point, is why I was ever getting the cached copy from pde.core. I would have thought the copy from doc.isv would always be available (as long as I have the plugin in my <eclipse home>/plugins). The new doc generation in tandem with the new css fixes the validation issues, but a little bit more investigation is required to ensure that a user will never have a new doc with an old css reference. When this happens, things look very very ugly.
This fix is in the build as of right now. If UA can't update the schema definitons/css file, we will have to retarget for M3.
