I am just migrating our EMF-based tools from Jadex 2.0 RC6 to Jadex 2.2. I realized that the BDI and Application XSDs no longer have separate namespaces. Instead, they share a common namespace with the new Component XSD. Is this intentional? Unfortunately, this design confuses EMF-based tools. For example, let X be a concept of the Component XSD. As X is imported to the Application XSD a concept X' is created. X' is identical to X, has the same name, and is in the same namespace. As X is imported to the BDI XSD, a further X'' is introduced. Now, there are multiple (identical) definitions of X in the same namespace. I tried several workarounds in EMF to disentangle the different declarations but I was not successful. Of course, it is not an option for me to change the URIs. The other Jadex XSDs have own namespaces. What was the reason for merging the namespaces? There is also a comment in the BDI XSD which says "Hack!!! The following combined restriction/extension is actually not valid XSD but works for eclipse XML editor." Is this related to my problem? I will continue looking for a workaround in EMF but If I can't find a solution I have to stick to RC6 /-: Thanks for your help!
- we wanted to have an easy way how a BDI programmer can write his XMLs. If component and BDI would not share the same namespace one would have explicitly to state bdi:belief etc.
- we also wanted to have a hierarchy of the schema, being component the root and BDI the extension in order to avoid modifying BDI and application XSD only because of changes in the component xsd.
If you just want to generate code from the BDI xsd it might be sufficient to copy the component xsd part to the BDI one instead of using the inheritance.
If you have other ideas they are very welcome.
thanks for your quick response. In my opinion, the problem is caused by the xs:redefine statement. The following link has an interesting section, called "Redefine as an issue" (it is mentioned that xs:redefine is deprecated):
I convert your XSD files to an Ecore metamodel. The xs:redefine element seems to be incompatible with the object-oriented (Java) world. For example: If you want to specialize a class definition in Java, you have to create a new class that has a different name and/or namespace. xs:redefine extends a definition without changing the name nor the namespace. Thus, there are multiple definitions of the same element around (which is pretty weird to me). I could try to rename all elements as they are redefined. E.g., I could try to assign X' the name X1 and X'' the name X2 (not sure whether this is supported by XSD… probably not). However, in my opinion the cleanest solution would be to replace the xs:redefine by an import of the schema file. For example, you could import the component.xsd into the bdi.xsd and specialize the concepts you want to extend (different name; e.g. X' becomes X_BDI). However, I am not an XSD expert.
one problem is that the xsd component type allows some tags (e.g. <argument>),
which are not allowed for the extended agent/capability type (e.g. because arguments are mapped to beliefs).
I think, this is not possible with an import. The only alternative would be copying some declarations from
the component.xsd to the bdi.xsd, which leads to duplicate code and thus reduced maintainability.
I have to check how much code needs to be copied for being able to decide if
this would actually more clean.
do you already know how you want to proceed? Are you going to change something or will everything stay the same?
I uploaded modified versions of the schemas to:
Let me know, if they work better for you.
thanks for your effort! At the first sight, it seems like that it works better now for my purpose. I will evaluate it in more detail and provide you feedback.
Thanks a lot,
the new XSD files work well for my purpose. I copied the content of the application XSD to the new BDI XSD and converted it to Ecore. The validation errors I had before are all gone. So, from my side I prefer the new version.
glad to hear that. I think we will stick to this new version, then.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.