Home » Modeling » EMF » Problem resolving proxies using URN
| Problem resolving proxies using URN [message #729585] |
Mon, 26 September 2011 14:48  |
Eclipse User |
|
|
|
Originally posted by: Patrick Kapahnke
Hi,
we encountered a problem with proxy resolution when using URIs of the
form urn:xml3d:shader:phong.
Starting from a xsd containing (among others) the following attribute
definition
<attribute default="" name="script" type="anyURI"
ecore:reference="xml3d:ScriptType">
</attribute>
we successfully generated an ecore model defining ScriptType and
containing the script reference according to this attribute (with
ResolveProxies == true).
The mechanism works fine for URIs with fragment parts when loading
resources in our application.
However, we defined some URNs for common script objects in the
application context (like urn:xml3d:shader:phong) and want to map them
to definitions located at some distinct position during the URIConverter
normalization process.
Unfortunately, this already fails in the
org.eclipse.emf.ecore.xmi.impl.XMLHandler.setValueFromId() method, since
it tries to identify a URI by looking for the fragment # character.
Moreover, URNs as the example given above result in this method to
classify the id as QName, which at the end results in having null
instead of a ScriptType object in the model.
Is this the expected behaviour for this? And is it possible to
circumvent this problem somehow? Any help is highly appreciated.
Best regards,
Patrick Kapahnke
|
|
|
| Re: Problem resolving proxies using URN [message #729591 is a reply to message #729585] |
Mon, 26 September 2011 15:26  |
 Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Patrick,
Comments below.
On 26/09/2011 7:48 AM, Patrick Kapahnke wrote:
> Hi,
>
> we encountered a problem with proxy resolution when using URIs of the
> form urn:xml3d:shader:phong.
>
> Starting from a xsd containing (among others) the following attribute
> definition
>
> <attribute default="" name="script" type="anyURI"
> ecore:reference="xml3d:ScriptType">
> </attribute>
>
> we successfully generated an ecore model defining ScriptType and
> containing the script reference according to this attribute (with
> ResolveProxies == true).
>
> The mechanism works fine for URIs with fragment parts when loading
> resources in our application.
>
> However, we defined some URNs for common script objects in the
> application context (like urn:xml3d:shader:phong) and want to map them
> to definitions located at some distinct position during the
> URIConverter normalization process.
>
> Unfortunately, this already fails in the
> org.eclipse.emf.ecore.xmi.impl.XMLHandler.setValueFromId() method,
> since it tries to identify a URI by looking for the fragment #
> character. Moreover, URNs as the example given above result in this
> method to classify the id as QName, which at the end results in having
> null instead of a ScriptType object in the model.
>
> Is this the expected behaviour for this?
Yes. We need to have a URI with a fragment; the base URI is used to
locate the resource and the fragment is used to locate the object within
that resource.
> And is it possible to circumvent this problem somehow?
Not easily. You'd have to specialize setValueFromId and turn that urn
into a URI that includes a fragment.
> Any help is highly appreciated.
You'd also need to do something to specialize how things are saved,
because the reference will still end up being
<uri-of-resource>#<fragment-in-resource> in that case.
>
> Best regards,
> Patrick Kapahnke
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Problem resolving proxies using URN [message #729938 is a reply to message #729591] |
Tue, 27 September 2011 10:22 |
Kristian Sons
Messages: 27
Registered: July 2009 |
Junior Member |
|
|
Hi,
wouldn't it be a good feature, if the URIResolver decides whether the
URI should refer to a EMF Resource or to a specific EMF Object?
For instance the URN urn:isbn:0451450523 refers to a book with this isbn
number. But perhaps I would like to have all books in a resource and
this URN just delivering an EObject from this resource, thus urn:isbn
would reference the Resource and 0451450523 the Object in the resource.
What do you think?
Best,
Kristian
> Patrick,
>
> Comments below.
>
> On 26/09/2011 7:48 AM, Patrick Kapahnke wrote:
>> Hi,
>>
>> we encountered a problem with proxy resolution when using URIs of the
>> form urn:xml3d:shader:phong.
>>
>> Starting from a xsd containing (among others) the following attribute
>> definition
>>
>> <attribute default="" name="script" type="anyURI"
>> ecore:reference="xml3d:ScriptType">
>> </attribute>
>>
>> we successfully generated an ecore model defining ScriptType and
>> containing the script reference according to this attribute (with
>> ResolveProxies == true).
>>
>> The mechanism works fine for URIs with fragment parts when loading
>> resources in our application.
>>
>> However, we defined some URNs for common script objects in the
>> application context (like urn:xml3d:shader:phong) and want to map them
>> to definitions located at some distinct position during the
>> URIConverter normalization process.
>>
>> Unfortunately, this already fails in the
>> org.eclipse.emf.ecore.xmi.impl.XMLHandler.setValueFromId() method,
>> since it tries to identify a URI by looking for the fragment #
>> character. Moreover, URNs as the example given above result in this
>> method to classify the id as QName, which at the end results in having
>> null instead of a ScriptType object in the model.
>>
>> Is this the expected behaviour for this?
> Yes. We need to have a URI with a fragment; the base URI is used to
> locate the resource and the fragment is used to locate the object within
> that resource.
>> And is it possible to circumvent this problem somehow?
> Not easily. You'd have to specialize setValueFromId and turn that urn
> into a URI that includes a fragment.
>> Any help is highly appreciated.
> You'd also need to do something to specialize how things are saved,
> because the reference will still end up being
> <uri-of-resource>#<fragment-in-resource> in that case.
>>
>> Best regards,
>> Patrick Kapahnke
|
|
|
| Re: Problem resolving proxies using URN [message #730058 is a reply to message #729938] |
Tue, 27 September 2011 14:44 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Kristian,
Comments below.
On 27/09/2011 3:22 AM, Kristian Sons wrote:
> Hi,
>
> wouldn't it be a good feature, if the URIResolver decides whether the
> URI should refer to a EMF Resource or to a specific EMF Object?
There's no such thing as URIResolver. You can look how
ResourceSetImpl.getResource/getEObject are implemented.
>
> For instance the URN urn:isbn:0451450523 refers to a book with this
> isbn number.
Yes, but in which resource? How's the object found in that resource?
Does this work in browser?
> But perhaps I would like to have all books in a resource and this URN
> just delivering an EObject from this resource, thus urn:isbn would
> reference the Resource and 0451450523 the Object in the resource.
One might argue what's wrong with urn:isbn#0451450523 or
urn#isbn:0451450523 or isbn:#0451450523 or any number of schemes that
fits in well with the notion of a URI that identifiers a resource and an
object within the resource.
>
> What do you think?
EMF is complicated enough. Every little feature is yet one more thing
to document, test, support, maintain, and so on. And of course other
downstream clients will not be prepared to handle things that don't
fit. So better you specialize how URIs are handled and produced to
handle your case (I'm open to factoring base classes in a way to make
that easier) than to further complicate the framework as a whole.
>
> Best,
> Kristian
>
>> Patrick,
>>
>> Comments below.
>>
>> On 26/09/2011 7:48 AM, Patrick Kapahnke wrote:
>>> Hi,
>>>
>>> we encountered a problem with proxy resolution when using URIs of the
>>> form urn:xml3d:shader:phong.
>>>
>>> Starting from a xsd containing (among others) the following attribute
>>> definition
>>>
>>> <attribute default="" name="script" type="anyURI"
>>> ecore:reference="xml3d:ScriptType">
>>> </attribute>
>>>
>>> we successfully generated an ecore model defining ScriptType and
>>> containing the script reference according to this attribute (with
>>> ResolveProxies == true).
>>>
>>> The mechanism works fine for URIs with fragment parts when loading
>>> resources in our application.
>>>
>>> However, we defined some URNs for common script objects in the
>>> application context (like urn:xml3d:shader:phong) and want to map them
>>> to definitions located at some distinct position during the
>>> URIConverter normalization process.
>>>
>>> Unfortunately, this already fails in the
>>> org.eclipse.emf.ecore.xmi.impl.XMLHandler.setValueFromId() method,
>>> since it tries to identify a URI by looking for the fragment #
>>> character. Moreover, URNs as the example given above result in this
>>> method to classify the id as QName, which at the end results in having
>>> null instead of a ScriptType object in the model.
>>>
>>> Is this the expected behaviour for this?
>> Yes. We need to have a URI with a fragment; the base URI is used to
>> locate the resource and the fragment is used to locate the object within
>> that resource.
>>> And is it possible to circumvent this problem somehow?
>> Not easily. You'd have to specialize setValueFromId and turn that urn
>> into a URI that includes a fragment.
>>> Any help is highly appreciated.
>> You'd also need to do something to specialize how things are saved,
>> because the reference will still end up being
>> <uri-of-resource>#<fragment-in-resource> in that case.
>>>
>>> Best regards,
>>> Patrick Kapahnke
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Problem resolving proxies using URN [message #730092 is a reply to message #729591] |
Tue, 27 September 2011 15:39 |
| Eclipse User |
|
|
|
Originally posted by: Patrick Kapahnke
Thanks for your quick reply.
As you said, I specialized setValueFromId to handle those cases and it
works fine. (Similar thing has to be done for saving, as you said, but I
don't think this will be a problem either).
Best,
Patrick
Am 26.09.2011 17:26, schrieb Ed Merks:
> Patrick,
>
> Comments below.
>
> On 26/09/2011 7:48 AM, Patrick Kapahnke wrote:
>> Hi,
>>
>> we encountered a problem with proxy resolution when using URIs of the
>> form urn:xml3d:shader:phong.
>>
>> Starting from a xsd containing (among others) the following attribute
>> definition
>>
>> <attribute default="" name="script" type="anyURI"
>> ecore:reference="xml3d:ScriptType">
>> </attribute>
>>
>> we successfully generated an ecore model defining ScriptType and
>> containing the script reference according to this attribute (with
>> ResolveProxies == true).
>>
>> The mechanism works fine for URIs with fragment parts when loading
>> resources in our application.
>>
>> However, we defined some URNs for common script objects in the
>> application context (like urn:xml3d:shader:phong) and want to map them
>> to definitions located at some distinct position during the
>> URIConverter normalization process.
>>
>> Unfortunately, this already fails in the
>> org.eclipse.emf.ecore.xmi.impl.XMLHandler.setValueFromId() method,
>> since it tries to identify a URI by looking for the fragment #
>> character. Moreover, URNs as the example given above result in this
>> method to classify the id as QName, which at the end results in having
>> null instead of a ScriptType object in the model.
>>
>> Is this the expected behaviour for this?
> Yes. We need to have a URI with a fragment; the base URI is used to
> locate the resource and the fragment is used to locate the object within
> that resource.
>> And is it possible to circumvent this problem somehow?
> Not easily. You'd have to specialize setValueFromId and turn that urn
> into a URI that includes a fragment.
>> Any help is highly appreciated.
> You'd also need to do something to specialize how things are saved,
> because the reference will still end up being
> <uri-of-resource>#<fragment-in-resource> in that case.
>>
>> Best regards,
>> Patrick Kapahnke
|
|
|
Goto Forum:
Current Time: Thu Apr 25 06:07:10 GMT 2024
Powered by FUDForum. Page generated in 0.03357 seconds |
] 
Search
Help
Register
Login
Home
