Home » Modeling » OCL » Package name conflict caused OCL parsing to fail
| Package name conflict caused OCL parsing to fail [message #38665] |
Tue, 25 September 2007 22:51  |
Eclipse User |
|
|
|
Originally posted by: guruji.gmail.com
Hello,
I have two different packages in my environment:
urn:com:XYZ:platform:shared
urn:com:XYZ:ui:shared
formed from two different XML schema documents with the above URNs.
When I write an OCL expression like
self.oclAsType(shared::MyPlatformType), where MyPlatformType exists in the
first package, it parses fine.
But when I write an OCL expression like self.oclAsType(shared::MyUIType),
where MyUIType exists in the second package, it fails to parse.
What do I do to avoid the conflict/collision in the package names. I tried
fully qualifying the package name in the OCL but it doesn't work.
Thank you for your help.
Satish
|
|
|
| Re: Package name conflict caused OCL parsing to fail [message #38818 is a reply to message #38665] |
Wed, 26 September 2007 13:59  |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Satish,
I don't understand the single-colon (':') form of these names. Do you have
packages named (in OCL/UML terms) as follows?
com::XYZ::platform::shared
com::XYZ::ui::shared
The resolution of package names depends on the namespace (usually a package)
in which the context classifier is defined. Say we have the following
classes:
in package com::XYZ::platform::shared
class A
class B has property a of type A
in package com::XYZ::ui::shared
class X has property a of type A
Then if in the the context of A we have
context com::XYZ::platform::shared::A
inv: B.allInstances()->forAll(a <> self)
inv: shared::B.allInstances()->forAll(a <> self)
inv: platform::shared::B.allInstances()->forAll(a <> self)
inv: com::XYZ::platform::shared::B.allInstances()->forAll(a <> self)
all of the above references to B should resolve but in
context com::XYZ::platform::shared::A
inv: X.allInstances()->forAll(a <> self)
inv: shared::X.allInstances()->forAll(a <> self)
inv: ui::shared::X.allInstances()->forAll(a <> self)
inv: com::XYZ::ui::shared::X.allInstances()->forAll(a <> self)
only the last two references to X above should resolve. The lookup of
partially qualified names backtracks up the containing namespaces of the
context classifier to try to find a match.
So, resolution of these names depends on the context classifier in which the
reference is made.
HTH,
Christian
Satish wrote:
> Hello,
> I have two different packages in my environment:
> urn:com:XYZ:platform:shared
> urn:com:XYZ:ui:shared
>
> formed from two different XML schema documents with the above URNs.
>
> When I write an OCL expression like
> self.oclAsType(shared::MyPlatformType), where MyPlatformType exists in the
> first package, it parses fine.
>
> But when I write an OCL expression like self.oclAsType(shared::MyUIType),
> where MyUIType exists in the second package, it fails to parse.
>
> What do I do to avoid the conflict/collision in the package names. I tried
> fully qualifying the package name in the OCL but it doesn't work.
>
> Thank you for your help.
>
> Satish
|
|
|
| Re: Package name conflict caused OCL parsing to fail [message #39133 is a reply to message #38818] |
Wed, 26 September 2007 21:59 |
| Eclipse User |
|
|
|
Originally posted by: guruji.gmail.com
Hi Christian,
Thanks for the prompt reply!
I have single-colon separated namespaces because I generated my EMF
Ecore model from a set of XML schemas. Those schemas (defined by others)
are also used to generate JAXB classes and that's how they defined the
namespaces in them for their purposes.
I have had no problem so far with these namespaces and have written
over a hundred validation rules using OCL without having to fully qualify
the namespaces. So shared::TypeA only meant com.XYZ.platform.shared.TypeA.
Recently, the schemas were changed and this namespace collision came up
and some rules are broken. Now shared in shared::TypeB seems to be
interpreted as com.XYZ.platform.shared.TypeB when in fact I mean
com.XYZ.ui.shared.TypeB. In fact, there is no TypeB in platform. I tried
ui.shared.TypeB, XYZ.ui.shared.TypeB and com.XYZ.ui.shared.TypeB but I get
an error:
ERROR in (enumerationOrClassLiteralExpCS): (Unknown type ([com, XYZ, ui,
shared, TypeB]))
I can only think of two reasons why it doesn't work for me:
1. The backtracking resolution you mentioned is not present in version
1.0.1 which is what I am using
(org.eclipse.emf.ocl_1.0.1.v200609250830.jar).
2. The backtracking resolution doesn't work for colon-separated
namespaces. It only works for dot-separated namespaces.
Any idea what I could do to make this work?
Thanks a lot.
Satish
|
|
|
| Re: Package name conflict caused OCL parsing to fail [message #39195 is a reply to message #39133] |
Wed, 26 September 2007 22:32 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Satish,
The OCL specification doesn't recognize ":" or "." as a namespace separator,
only "::". However, MDT OCL 1.0.1 is is Ecore-based, and it is not common
for EPackages to be nested. You can reference EPackages by qualified name
using "::" separators if you actually have EPackage nesting, or by *either*
the EPackage's name or nsPrefix.
So, say you have the following:
EPackage com
- name = com
- nsPrefix = com
EPackage XYZ
- name = XYZ
- nsPrefix = com.XYZ
EPackage ui
- name = ui
- nsPrefix = com.XYZ.ui
EPackage shared
- name = shared
- nsPrefix = com.XYZ.ui.shared
Then you should be able to do, for example,
self.oclAsType(com::XYZ::ui::shared::TypeB)
Evidently, that isn't working, so you probably don't have this kind of
package nesting.
If, instead, you have the following:
EPackage shared
- name = shared
- nsPrefix = com.XYZ.ui.shared
then you should be able to do:
self.oclAsType(com.XYZ.ui.shared::TypeB)
using MDT OCL 1.0.1's special ability to refer to EPackages by their
nsPrefix attribute instead of their name. Note, however, the "::"
separating the package from the class. The EClass *is* nested in the
EPackage.
Finally, suppose you have the following:
EPackage shared
- name shared
- nsPrefix = com:XYZ:ui:shared
then you might think that should be able to do
self.oclAsType(com:XYZ:ui:shared::TypeB)
but I expect it would not work because the ":" characters will confuse the
parser because they separate tokens for a different purpose than qualified
names.
Perhaps you can try extending the EcoreEnvironment implementation (and
EcoreEnvironmentFactory, too) to customize the package look-up algorithm
for your package names, so that you can use "com::XYZ::ui::shared" to
distinguish your package despite the fact that it isn't actually composed
of nested EPackages.
HTH,
Christian
Satish wrote:
> Hi Christian,
> Thanks for the prompt reply!
> I have single-colon separated namespaces because I generated my EMF
> Ecore model from a set of XML schemas. Those schemas (defined by others)
> are also used to generate JAXB classes and that's how they defined the
> namespaces in them for their purposes.
> I have had no problem so far with these namespaces and have written
> over a hundred validation rules using OCL without having to fully qualify
> the namespaces. So shared::TypeA only meant com.XYZ.platform.shared.TypeA.
> Recently, the schemas were changed and this namespace collision came up
> and some rules are broken. Now shared in shared::TypeB seems to be
> interpreted as com.XYZ.platform.shared.TypeB when in fact I mean
> com.XYZ.ui.shared.TypeB. In fact, there is no TypeB in platform. I tried
> ui.shared.TypeB, XYZ.ui.shared.TypeB and com.XYZ.ui.shared.TypeB but I get
> an error:
> ERROR in (enumerationOrClassLiteralExpCS): (Unknown type ([com, XYZ, ui,
> shared, TypeB]))
> I can only think of two reasons why it doesn't work for me:
> 1. The backtracking resolution you mentioned is not present in version
> 1.0.1 which is what I am using
> (org.eclipse.emf.ocl_1.0.1.v200609250830.jar).
> 2. The backtracking resolution doesn't work for colon-separated
> namespaces. It only works for dot-separated namespaces.
>
> Any idea what I could do to make this work?
> Thanks a lot.
>
> Satish
|
|
|
| Re: Package name conflict caused OCL parsing to fail [message #39537 is a reply to message #39195] |
Sat, 29 September 2007 00:23 |
| Eclipse User |
|
|
|
Originally posted by: guruji.gmail.com
Hi Christian,
Thanks very much for the explanation.
As you correctly guessed, I don't have nested packages. It just so happens
that all my packages have their NS_PREFIX
the same as their NAME. The only distinguishing attribute is NS_URI. So I
tried to solve my problem by, as you suggested, extending EcoreEnvironment
and EcoreEnvironmentFactory and adding in a findPackageByNSUri analogous
to the findPackageByNSPrefix.
But there was a problem: the parser seemed to be eating up my tokens.
So if I tried:
self.oclAsType(com::XYZ::shared::ui::types::shared::TypeB)
I got:
ERROR in (enumerationOrClassLiteralExpCS): (Unknown type ([com, XYZ,
shared, ui, types, TypeB]))
the last 'shared' is missing.
If I tried:
self.oclAsType(com::XYZ::shared::ui::types::XYZ::shared::Typ eB)
I got:
ERROR in (enumerationOrClassLiteralExpCS): (Unknown type ([com, XYZ,
shared, ui, types, TypeB]))
There's only one XYZ and one shared.
I didn't dig into how the parser works but I wonder if it is extracting
the tokens into a Set and losing some along the way.
Of course, not many people will have repeating tokens in their package
names but we happen to.
So I now use an underscore separated format to specify the package in my
OCL statement and it all works fine.
self.oclAsType(com_XYZ_shared_ui_types_shared::TypeB)
My findPackageByNSUri compares this entire string to the NS_URI and
fetches the right package.
Thanks,
Satish
|
|
|
| Re: Package name conflict caused OCL parsing to fail [message #39662 is a reply to message #39537] |
Mon, 01 October 2007 13:39 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Satish,
See some replies in-line, below.
HTH,
Christian
Satish wrote:
> Hi Christian,
> Thanks very much for the explanation.
> As you correctly guessed, I don't have nested packages. It just so happens
> that all my packages have their NS_PREFIX
> the same as their NAME. The only distinguishing attribute is NS_URI. So I
> tried to solve my problem by, as you suggested, extending EcoreEnvironment
> and EcoreEnvironmentFactory and adding in a findPackageByNSUri analogous
> to the findPackageByNSPrefix.
> But there was a problem: the parser seemed to be eating up my tokens.
>
> So if I tried:
> self.oclAsType(com::XYZ::shared::ui::types::shared::TypeB)
> I got:
> ERROR in (enumerationOrClassLiteralExpCS): (Unknown type ([com, XYZ,
> shared, ui, types, TypeB]))
>
> the last 'shared' is missing.
>
> If I tried:
> self.oclAsType(com::XYZ::shared::ui::types::XYZ::shared::Typ eB)
> I got:
> ERROR in (enumerationOrClassLiteralExpCS): (Unknown type ([com, XYZ,
> shared, ui, types, TypeB]))
>
> There's only one XYZ and one shared.
Are you using MDT OCL 1.0.x? This is a symptom of a bug that was fixed in
the 1.1 release. The CST implementation of pathNameCS declared the
sequenceOfNames attribute as unique instead of non-unique. The result was
that the list of strings would not accept duplicates.
> I didn't dig into how the parser works but I wonder if it is extracting
> the tokens into a Set and losing some along the way.
> Of course, not many people will have repeating tokens in their package
> names but we happen to.
>
> So I now use an underscore separated format to specify the package in my
> OCL statement and it all works fine.
>
> self.oclAsType(com_XYZ_shared_ui_types_shared::TypeB)
>
> My findPackageByNSUri compares this entire string to the NS_URI and
> fetches the right package.
Maybe this is better, anyway, to be more clear that this is a single name
segment? It shouldn't have to be this way, but if you're using 1.0.x, then
you're stuck, I guess. Anyway, I'm glad that you got it working!
> Thanks,
> Satish
|
|
| |
Goto Forum:
Current Time: Thu Sep 26 22:12:57 GMT 2024
Powered by FUDForum. Page generated in 0.04225 seconds |
] 
Search
Help
Register
Login
Home
