Another approach might be to create a schema that represents the combined schemas of all three and just include the other XSD files using something like:
<xs:include schemaLocation="widget-screen.xsd"/> As long as they are all in the same directory this should work fine. You'll probably need to give it a new root element that allows all of the different screen, form, etc sub-elements to make it useful. Chances are you'll run into conflicting element names too. The widgets should have been done this way from the beginning, ie using various includes, so that things like the actions element could be defined in one place and shared between all of the different types of widgets, instead of having small variations between each (which developed by lack of checking for consistency). BTW, I'm not sure if putting different types of widgets or other things in the same file is a good idea (I guess only time can tell), but it should be possible. -David On Jan 1, 2011, at 3:10 PM, Adrian Crum wrote: > It's not an issue of conflicting element names. It's an issue because all of > the widget XML files expect to have only one schema. If you have screens, > forms, and menus all in one file, then you need to support multiple schemas. > > I have it basically working - I just need to figure out a validation error. > The existing schemas don't have a TargetNamespace defined, which causes an > error. If I add a TargetNamespace, then I get a different error saying it was > expecting it to be empty. ::scratches head:: > > I'll post a patch on Jira, maybe an XML expert can figure it out. > > -Adrian > > --- On Sat, 1/1/11, David E Jones <[email protected]> wrote: > >> From: David E Jones <[email protected]> >> Subject: Re: Discussion: Support Screen Widget Namespaces >> To: [email protected] >> Date: Saturday, January 1, 2011, 2:39 PM >> >> What are the conflicting element names you are seeing that >> would require the use of namespaces? >> >> -David >> >> >> On Jan 1, 2011, at 10:15 AM, Adrian Crum wrote: >> >>> The current system of having separate XML files for >> screens, menus, and forms lends itself well to some types of >> projects. In some cases, it might be preferable to have all >> related widgets (screens, forms, menus) in a single XML >> file. >>> >>> Adding support for multiple widget types in a single >> file would require a small change to the widget factory >> code. The "compound widget" XML file would require the use >> of namespaces - but the added complication is minimal. >>> >>> Would there be any interest in that? >>> >>> -Adrian >>> >>> >>> >>> >>> >> >> > > >
