Community
Participate
Working Groups
I200410260800 In our "popupMenus.exsd" schema, we include the "org.eclipse.core.expressions" enablement language schema. Our schema defines an "enablement" element, which it expects to be populated by the "org.eclipse.core.expressions" enablement language schema. Unfortunately, it appears as though the "test" element (can be contained by "enablement") is being reported as an illegal child. Why is this happening?
Doug, this schema itself declares an <enablement> element, AND includes such an element from the core.expressions schema. One of them arbitrarily wins, and in this case, it is not the one you want. I suggest you delete your local <enablement> element from the schema.
I misspoke. In the case of two elements of the same name, the local one always wins. It is not arbitrary.
douglas_pollock@ca: We include only seem to be defining the element grammar. We don't seem to be defining the element itself. douglas_pollock@ca: How do we define how many of an included element can be a sub-element of one of our defined elements? Wassim Melhem: I looked at the HTML version of the schema and it certainly appears as though you are both declaring the element and reincluding an element of the same name. Wassim Melhem: two definitions of <enablement> douglas_pollock@ca: popupMenus.exsd? douglas_pollock@ca: I can't find any elements called enablement. douglas_pollock@ca: I can find them as part of a complex type (i.e., specifying the number to be included). douglas_pollock@ca: Am I looking at this the wrong way? Wassim Melhem: right-click on it and select PDE Tools > Preview reference document, and then see how many <enablement> definition you can find. Wassim Melhem: you will see two: one good, one bad douglas_pollock@ca: I'm looking at XML itself. douglas_pollock@ca: Where is it poorly defined there? Wassim Melhem: let me take a look at the schema itself Wassim Melhem: you're including two <enablement> elements: one from commonExpression.exsd and one from expressionLanguage.exsd
I believe the problem is the change made for Bug 59963. This leads to duplicate definitions. Some definitions in "commonExpression.exsd" and "expressionLanguage.exsd" are the same, but there are some that are unique to each. To complicate matters, the "commonExpression.exsd" schema is used by several other extensions points (i.e., other than "popupMenus.exsd"). So, changing this file will affect the others as well, and these other extension points are not aware of the core expressions support. It's just a compiler error, and it seems like it might take significant effort to fix it. It also affects documentation. Assigning to Tod, as he owns Contributions. However, adding Nick Edgar, MVM, Erich Gamma and Dirk Baeumer as I believe the duplicate came from a patch they worked on collectively.
Uniqueness of plug-in names in general XML world is achieved through name spaces. However, I don't think we should go down that route either in extension point schemas (where we would need to add namespace support) nor in plugin.xml. As it stands now (ignoring the compiler error for a sec), I don't know how the extension consumer is going to treat elements of the same name that belong to two different schemas (using 'schema' conceptually here). It seems to be that avoiding this name collision would be the best solution for reasons other than to avoid confusing PDE.
*** Bug 77018 has been marked as a duplicate of this bug. ***
As the platform evolves, namespace collisions like this are going to occur. Changing the schemas to avoid a collision is typically a non-starter due to backwards compatibility requirements. In this case, it would be a breaking API change to change either org.eclipse.ui.popupMenus or org.eclipse.core.expressions. It's -very- confusing to the developer when collisions like this happen, with our current tooling support. In order to have the PDE checker and other tooling be accurate (not to mention just the documentation), such collisions need to be resolved accurately. I think we need to move to a stronger definition of namespaces for extension point schemas. Please consider adding this support to PDE.
Just to make this clear: the fact that elements from different schemas can appear in plugin.xml is not confusing the code? In other words, an element 'foo' in one context is clearly resolved as 'commonExpressions:foo', and 'expressionLanguage:foo' in another and the code that reads the registry is not confused? If this is the case, the ball is back in PDE court.
Currently when we grovel through configuration elements, namespaces aren't used since they're not supported. If we were to support them, then the code would need to change accordingly, e.g. specify the URI for the namespace as well as the simple element name. We may need to consider adding API to IConfigurationElement to support this, e.g. getChildren(String namespace, String name).
We should distinguish between XML schema/validation and extension points. What happens in this example is that there is an extension point that uses the enablement element from core.expressions, not the one defined in popupMenus.exsd. The code that reads this extension point is aware of this. So when it processes the configuration element representing the enablement element it treats it as an expression element. So a first step would be that in schema file I can use name spaces to explicitly reference other elements. Something along the following lines: <element ref="org.eclipse.core.expressions.enablement" minOccurs="0" maxOccurs="1"/> instead of <element ref="enablement" minOccurs="0" maxOccurs="1"/> which in the given case always refers to the local one. This will remove the reported error. Supporting namespace in extension point definitions would be nice to have, but is only required when we want to support extension points that refers to n different elements having the same name. For example <extension point="org.eclipse.myExtension> <enablement ..... /> <=== enablement element from plug-in A <enablement ..... /> <=== enablement element form plug-in B </extension> It is not necessary to solve the problem described here.
My question all along was if the fact that there is name collision actually affects the code that reads the extension point or the only problem is with the validation. Since we established the later, Dirk's suggestion is most welcome because having a qualified referencing would be a fairly straightforward enhancement. For the benefit of PDE developers: 1) The schema editor needs to be modified so that grammar view shows qualified names of elements for which there would be a name collision in the simple form 2) Elements with a name collision should be fully qualified elsewhere in the schema editor AND also in the generated HTML document. XML namespace qualification should be used e.g. org.eclipse.core.expressions:enablement (note the use of ':' to separate the target namespace defined in the schema element of the schema and the simple name of the element). 3) Hyperlinks for quick jumps to the element declaration should be similarly qualified to avoid anchor duplication (because we recursively flatten the schema hierarchy when creating the reference document and all the elements will appear in the same document). Originating schemas should be found by matching the qualifying name space in the element name (<namespace>:<simple_name>) and 'targetNamespace' attribute in the declaration of the 'schema' element. I am sure I left couple of things out - this is just to get the creative juices flowing :-).
This proposal sounds good. I agree that we don't need the full generality of namespaces at this point, just extension point qualification, and just in the validation and other PDE tooling. Ideally we would do this in a way that would be compatible with XML namespaces, and which would still work if you do decide to support full XML namespaces further down the road. For example, it could work as if there was an explicit xmlns declaration mapping the full URI for the org.eclipse.core.expressions schema to the shortcut "org.eclipse.core.expressions". Should the qualifier refer to the plugin, the extension point, or the schema file itself?. Currently, schema files are either associated with a specific extension point, or are made available to be included from other schema files. It seems incorrect to take the union of the schema files in a particular plugin and refer to the union by the plugin id. For the case here, it would seem to make more sense to use "org.eclipse.core.expressions.expressionLanguage:enablement". This would effectively give schema files their own identity, which they don't currently have.
Actually, extension point schemas DO have their own namespace from the start. If you check any of your schemas, you will notice something like '<schema targetNamespace="xyz">' where xyz happens to be the full extension point Id. The attribute in question is valid in XML Schema spec and is used exactly as we plan to do it here. I doubt that we will ever go down the full namespace route though. Doing so would require declaring of all of the namespaces at the root element i.e. you would need to declare a name space for each extension point used in the file at the top, and point at the schemas that define the grammar for the name space in question (using xmlns attribute). This would be similar to 'import' package in Java where you must explicitly specify the package where the type is defined before using it further down. I checked with people who are considered XML experts and they agree that XML file validation is normally done at design time only (using validating parsers), but runtime parsers (e.g. used by core runtime) typically assume they are given a correct file. The reason they do is because there is nothing an end-user can do with an invalid file at runtime since the invalid file would come from a bundle they have no control over. Note that 'org.eclipse.core.expressions.expressionLanguage:enablement' is a correct qualification because 'org.eclipse.core.expressions.expressionLanguage' is formally declared as a target namespace in the shema. There is no point in going full bore in plugin.xml itself though, because we would need to turn the namespaces on and declare the namespaces at the top (which means that most of the plugin.xml files will fail the formal validation).
OK, using targetNamespace to (optionally) qualify elements in the schema sounds like the right thing to do. Thanks for enlightening me.
Hmm. Looks like we have to fix up a bunch of our targetNamespaces. All the schema files in org.eclipse.ui/schema specify: <schema targetNamespace="org.eclipse.ui"> instead of specifying the extension point id. This appears to be the default generated by PDE -- it uses the plugin id, not the full extension point id. The ones in org.eclipse.core.expressions need fixing as well. expressionLanguage.exsd has: <schema targetNamespace="org.eclipse.ui"> propertyTesters.exsd has: <schema targetNamespace="org.eclipse.jdt.ui"> "'org.eclipse.core.expressions.expressionLanguage' is formally declared as a target namespace in the shema" Did you see this somewhere else, or are you saying how it should be declared? Also, is the <meta.schema> element relevant at all? e.g. the org.eclipse.ui.popupMenus extension point schema has: <annotation> <appInfo> <meta.schema plugin="org.eclipse.ui" id="popupMenus" name="Pop-up Menus"/> </appInfo> </annotation> I assume this is not part of the XML schema proper since it's in an <annotation>, but how do we use it?
The 'meta' info is in the annotation and is used by PDE to back-link a schema to the plug-in that owns the extension point. The information is important but I would leave it as-is. As for targetNamespace, I suggest PDE developers to double-check the schema generation wizard and if needed, change the targetNamespace to be equal to the fully qualified extension point id. After that, we should ask schema owners to fix up their targetNamespace to be complete. I guess this will mostly affect org.eclipse.ui team since most of the shared schemas are there.
Changed expressionLanguage.exsd and propertyTesters.exsd to refer to the correct namespace and plug-in (as of today).
I'm going to wait for confirmation from the PDE folk before changing the targetNamespaces in UI land.
Everybody, please do not make any changes until you hear back from PDE (folk)
I changed the traget namespace to be org.eclipse.core.expressions. It was org.eclipse.ui and org.eclipse.jdt.ui which is definitelly wrong.
*** Bug 77027 has been marked as a duplicate of this bug. ***
In bug 78158 I asked Debug team for an estimate when this will be fixed (since the error appears on their plugin.xml). I guess I have to forward this question to this bug now since it was closed as dup.
while I can't put an exact date on it, it would be on of the first few things addressed in the M4 cycle.
an update: supporting multiple namespaces in schemas is going to be an elaborate piece of work that we won't be able to contain in M4. In the meantime, I suggest setting this flag to IGNORE in the "Plug-in Manifest Compiler" property page of the project showing the problem.
I have changed the debug projects to "warn" rather than "error".
I was reading through this bug posting and wanted to add a few knowledge bits of XML Schema that might be useful when adding a little bit of namespacing support to extension points schemas. - <include schemaLocation="" /> is really used for different purposes in XML Schema. Basically, you use it when the current and the included targetNamespace matches (an actual schema rule). More like when you just want to include the contents as yours. (i.e. your are just componentizing your entire schema into different files). - <import namespace="" schemaLocation="" /> is meant for the case in which you want to reference other schema elements in your current schema complexType definitions. Maybe introduce this and warn/deprecate the old method, while maintaining backward compatability. - @ref and @type attributes should in fact be QNames (qualified names), but in plugin.xml we only use type="string", which is not equivalent to xsd:string. I'm just saying this, but a simple xmlns="http://xsd-uri" would solve it at the top of the schema declaration. - 'org.eclipse.expressions' is not a valid namespace, because it's not a URI/URN, but we'll have to live with this one. - In the case where we did two imports that have the 'enablement' element and you would like to use it in a @ref, ,my recommendation is that you should not use the 'org.eclipse.expressions:enablement' approach. ':' are mostly used for in elements/qnames for separating namespace prefixes and not the actual namespace from the local name. I would recommend a non-official, but more of a convention to use UName. Universal names, <element ref="{org.eclipse.ui}enablement" />. This is safer, because {} are not allowed in URIs and avoids the use of ':' which could be part of an actual attribute value. Finally, if we are going to used prefixed elements references in the final plugin.xml, those namespaces should be declared at the root of the plugin.xml files in the case that you wouldn't want to type '{org.eclipse.ui}' everywhere. I hope these comments are helpful to Wassim or others when adding a fix to the existing duplicate elements name problems. I'm also available if you have any questions.
Is this for 3.1? Bug 77021 (blocked by this bug) is currently assigned to me and marked as 3.1. If this bug is not going to be addressed for 3.1, then I'd like to defer Bug 77021 as well.
Please see comment #27. Is this for 3.1?
not going to happen for 3.1
*** Bug 79122 has been marked as a duplicate of this bug. ***
*** Bug 98694 has been marked as a duplicate of this bug. ***
*** Bug 120718 has been marked as a duplicate of this bug. ***
Wassim, are there plans to address this in 3.2? thanks, Andrew
no.
deferring to post-3.2
*** Bug 132700 has been marked as a duplicate of this bug. ***
*** Bug 170020 has been marked as a duplicate of this bug. ***
This is confusing and severely impacts client productivity.
*** Bug 173007 has been marked as a duplicate of this bug. ***
So, yet another duplicate. Can this be reopened and fixed for 3.3?
In order to fully support namespaces in extension point schemas, it would be a huge amount of work and all existing schemas out there in the world will have to be migrated. Does not seem worth the effort since the only extension point that exhibits this clash of namespaces is the soon-to-be-deprecated popupmenus extension point. Unless there is another issue that I am not aware of, comment 38 seems a bit over-the-top characterization of the issue.
(In reply to comment #41) > In order to fully support namespaces in extension point schemas, it would be a > huge amount of work and all existing schemas out there in the world will have > to be migrated. Only schemas with clashes would have to be updated (only popupMenus.exsd, so far) > Does not seem worth the effort since the only extension point that exhibits > this clash of namespaces is the soon-to-be-deprecated popupmenus extension > point. I doubt that the popupMenus extension point will be deprecated before 4.0. > Unless there is another issue that I am not aware of, comment 38 seems a bit > over-the-top characterization of the issue. The issue is apparent when you count the number of dups and CCs here and for bug 111778 (recursively).
As of now 'LATER' and 'REMIND' resolutions are no longer supported. Please reopen this bug if it is still valid for you.
