| Improve XMLResourceImpl's URI Fragments upon serialization [message #1739063] |
Wed, 27 July 2016 09:33  |
 Michael Longo
Messages: 8
Registered: July 2015 |
Junior Member |
|
|
Hi,
For our internal needs, we upgraded our resource implementation to change how references are generated / read upon (de)serialization.
In our model, we have ids only on specific elements and not on the element contained into the said elements. But we also have a lot of references toward contained elements (and therefore without ids).
The "issue" we had was that the XMLResource generates references like:
"<resource>#<fragment uri>"
Where <fragment uri> is either <id> or <xpath-like>.
So we ended up with a lot of references looking like:
"<parent href="file.ext#//@elm1.0/@positions.1/@item.0/@description"/>"
Which is kind of lame because "//@elm1.0/@positions.1/@item.0" is an element with an id.
So, to make the long story short, we changed the generation to generate:
"<parent href="file.ext#<item id>/@description"/>"
Basically, it looks into the container of the element, looks for the closest id, and starts the xpath from the element prefixing by its id. (and if no element have an id, the full xpath is generated)
All this explanation just to ask you: do you think it is worth contributing our change to the XMLResourceImpl? (I mean to make a ticket, a pull request and so on)
Thanks,
Michael.
|
|
|
| Re: Improve XMLResourceImpl's URI Fragments upon serialization [message #1739068 is a reply to message #1739063] |
Wed, 27 July 2016 10:17  |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
That sounds like https://bugs.eclipse.org/bugs/show_bug.cgi?id=494506 right?
On 27.07.2016 11:33, Michael Longo wrote:
> Hi,
>
> For our internal needs, we upgraded our resource implementation to
> change how references are generated / read upon (de)serialization.
>
> In our model, we have ids only on specific elements and not on the
> element contained into the said elements. But we also have a lot of
> references toward contained elements (and therefore without ids).
>
> The "issue" we had was that the XMLResource generates references like:
> "<resource>#<fragment uri>"
>
> Where <fragment uri> is either <id> or <xpath-like>.
>
> So we ended up with a lot of references looking like:
> "<parent href="file.ext#//@elm1.0/@positions.1/@item.0/@description"/>"
>
> Which is kind of lame because "//@elm1.0/@positions.1/@item.0" is an
> element with an id.
>
> So, to make the long story short, we changed the generation to generate:
> "<parent href="file.ext#<item id>/@description"/>"
> Basically, it looks into the container of the element, looks for the
> closest id, and starts the xpath from the element prefixing by its id.
> (and if no element have an id, the full xpath is generated)
>
> All this explanation just to ask you: do you think it is worth
> contributing our change to the XMLResourceImpl? (I mean to make a
> ticket, a pull request and so on)
>
> Thanks,
> Michael.
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Improve XMLResourceImpl's URI Fragments upon serialization [message #1739069 is a reply to message #1739068] |
Wed, 27 July 2016 10:18 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
And it does sound useful. There are cases in Oomph where this would
help prevent errors when people textually merge the serialized setup
instances...
On 27.07.2016 12:17, Ed Merks wrote:
> That sounds like https://bugs.eclipse.org/bugs/show_bug.cgi?id=494506
> right?
>
>
> On 27.07.2016 11:33, Michael Longo wrote:
>> Hi,
>>
>> For our internal needs, we upgraded our resource implementation to
>> change how references are generated / read upon (de)serialization.
>>
>> In our model, we have ids only on specific elements and not on the
>> element contained into the said elements. But we also have a lot of
>> references toward contained elements (and therefore without ids).
>>
>> The "issue" we had was that the XMLResource generates references like:
>> "<resource>#<fragment uri>"
>>
>> Where <fragment uri> is either <id> or <xpath-like>.
>>
>> So we ended up with a lot of references looking like:
>> "<parent href="file.ext#//@elm1.0/@positions.1/@item.0/@description"/>"
>>
>> Which is kind of lame because "//@elm1.0/@positions.1/@item.0" is an
>> element with an id.
>>
>> So, to make the long story short, we changed the generation to generate:
>> "<parent href="file.ext#<item id>/@description"/>"
>> Basically, it looks into the container of the element, looks for the
>> closest id, and starts the xpath from the element prefixing by its
>> id. (and if no element have an id, the full xpath is generated)
>>
>> All this explanation just to ask you: do you think it is worth
>> contributing our change to the XMLResourceImpl? (I mean to make a
>> ticket, a pull request and so on)
>>
>> Thanks,
>> Michael.
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
|
Powered by
FUDForum. Page generated in 0.03085 seconds
] 
Search
Help
Register
Login
Home
