Community
Participate
Working Groups
I'm currently on 1.0m4. It doesn't appear that you can configure multiple .xsd files which all have the same targetNamespace -- the first one configured wins, whether through the user catalog or via the org.eclipse.wst.xml.uriresolver.catalogContributor extension point. This is problematic for me since I would like to have my plugins configure xsds for the xml editor to pick up, and we've got several cases where the namespace is split into multiple .xsd files for ease of development. Also, j2ee has multiple .xsds all in the same namespace (http://java.sun.com/xml/ns/j2ee), which means you can't set that up either without manually cat'ing all the files together.
Here's how I think we need to approach this. You can only register one schema 'by namespace'. In the case of included schemas this will be the 'mother' schema that likely includes all the others. For the other schemas of the same namespace you'll need to register these 'by location'. That how we've handled J2EE schemas in the past. For example... "http://java.sun.com/xml/ns/j2ee/application-client_1_4.xsd" ----> "/myschemas/application-client_1_4.xsd" "http://java.sun.com/xml/ns/j2ee/application_1_4.xsd" -----> "/myschemas/application_1_4.xsd" Please note that our XML/XSD vlidators currently have a bug in supporting this pattern (see bug 96155).
That seems like a fine workaround that I (as a plugin developer) could use with the extension point, but this still seems like a bug that should be addressed. This actually came up from someone I work with, who isn't writing plugins, and has a set of 4 xsds for a single targetNamespace (which don't import each other), and was trying to register them in the user XML Catalog. It doesn't seem right that he needs to create another xsd which imports all of them, and then register them all just right to get things to work.
Changed Version field given new release numbering.
Well there's no problem with registering multiple schemas in the catalog that happen to have the same namespace ... but in these cases you need to register them 'by location' (as opposed to 'by namespace'). We've handled the j2ee schemas in the past by registering them by 'schema location' and then our XML instances of these schemas need to provide schemaLocation attributes to identify the location. See comment #1 for examples.
Oops I should have mentioned. This is all do-able from the Catalog user interface. You don't need to be a plugin developer to do this. I doubt we could ever support registering multiple schemas with the same 'key'. I think our catalog needs to be smarter by informing you when more than one entry has been registered with a non-unique 'key' and perhaps suggesting an alternative approach. Let me know if you think that makes sense or if you have some other solution in mind.
I understand how it works now, and, looking at the catalog code, how you can only have 1 item mapped to a namespace or schemaLocation and how the resolver interfaces are designed around that. The issue I have is this: if I have already existing .xsd files, all with the same targetNamespace, but which do not import each other nor currently have a 'mother' schema, I cannot just register them and have them work. I have to either modify one to import the others (which might not be plausible given different development environments) or create an artifical xsd which does an import of each actual xsd, and then register them all appropriately (the artifical/mother one by namespace, the others by schemaLocation as specified in the mother's imports). I guess I'm just concerned this may not map onto some customers' current xsds, including my coworker's, plus can be confusing and error-prone. Like I mentioned above, for my actual current problem, I can create a mother schema and handle it that way, so I'm not blocked, so maybe this is actually an enhancement request.
I'm going to take Greg up on his comment 6 and change to enhancement request. (Still important! just bugzilla bookkeeping)
Greg, >The issue I have is this: if I have already existing .xsd files, all with the >same targetNamespace, but which do not import each other nor currently have a >'mother' schema, I cannot just register them and have them work. Yes you can. We do this today for the j2ee schemas. You simply need to register these by 'schema location' in the catalog and your XML files need to specify xsi:schemaLocation attributes. Perhaps you've got another solution in mind that you feel would be better? If so please describe it here and I'll be more than happy to look at implementing it (or accepting patches that implement it ;-)
> Yes you can. We do this today for the j2ee schemas. You simply need to > register these by 'schema location' in the catalog and your XML files need to > specify xsi:schemaLocation attributes. > Perhaps you've got another solution in mind that you feel would be better? If > so please describe it here and I'll be more than happy to look at implementing > it (or accepting patches that implement it ;-) Ideally, Web Tools shouldn't be relying on SchemaLocation for resolving this issue. I work for a Automotive Standards organization, and consistently steer people away from the use of SchemaLocation for identification of the schema. It's not a reliable method, and you should never use it for a production application. Like's greg scenario, we have over 127 different schemas, that all fall under one common namespace. It's not practical to include a 127 different schema locations, especially as it will change from end user to end user's machine. I would prefer, a list that could be choosen if used interactively, to allow the selection of which particular schema I would want. This be stored externally by the catalog, and not reliant on the schemaLocation. Even the W3C Specs, say SchemaLocation is a hint, an processors may over ride it.
Dave, do any of the specs give hints about how to solve this problem without using SchemaLocation? We don't have people to work on this just now, but high quality patches would still be reviewed.
(In reply to comment #10) > Dave, do any of the specs give hints about how to solve this problem without > using SchemaLocation? We don't have people to work on this just now, but high > quality patches would still be reviewed. > Typically, we recommend using the namespaces specified in the XML document, and in our case, the name of the root element to identify the particular schema to use. It's then up to the implementors to figure out the best way to use it. Several still use schemaLocation, but the problem with schemaLocation is that there is no standard way that tools have to handle it. And no particular format that it is required to be in. Some require a valid url, while others will take a file path. If you are using schemaLocation to do XMLCatalog lookups, then I would recommend using the default namespace or available namespaces defined to look up the entries, and only fall back to schemaLocation if you can't resolve it any other way.
One way of achieving this is to make a single 'mother' XSD schema for the namespace in question and then xsd:include all the individual schema file in the namespace. Then add that schema file to the XML Catalog. You would need to tell the validator about honouring all the schema locations, see bug 197947. Rely on WTP to do non-standard XML file validation based on XML catalog entries would be a really bad idea, IMHO, and be inconsistent/incompatible with other XML tools - recommending WONTFIX.
