| XMLTypeFactoryImpl fails to recreate QNames properly while "undoing change" [message #490996] |
Mon, 12 October 2009 17:42  |
 Kaniska Mandal
Messages: 34
Registered: July 2009 |
Member |
|
|
Hi All,
problem description : I am using EMF .4.x.v200902171115 - to develop a tool and I see that QNames are not getting resolved properly when I undo my change !
detail steps :
1. Lets assume : we have an EList mySpaces which hold a list of QNames
-- persisted as
<mydomain:myModel .. xmlns:xyz = "http://www/xyz.com/"
<mydomain:mySpace horizon="xyz:myQName" /> ...
2. somewhere in system a RecordingCommand fires to clear the list of qnames-
mySpacesEList.getHorizons().removeAll()
3. while removing the qname, emf prepares a List of changes and includes
removed qname value in that list as follows ...
-- ListChangeImpl#DataValueDelegatingList#
-- new DelegatingEList() {
-- validate(index, object)
-- ECoreUtil.convertToString(type, object)
-- XMLTypeFactoryImpl#convertQNameToString(type, instanceVal)
*** now here instanceVal is a QName
with targetNS =http://www/xyz.com/
localpart=myQName
prefix=xyz
*** returns "xyz:myQName"
** here its important to note that emf does not append targetNS in the
converted string !!
4. Next, I undo my change from UI .. so emf tries to retrieve the saved
changes and convert them back into relevant objects ..
-- ListChangeImpl#DataValueDelegatingList#
-- new DelegatingEList() {
-- resolve(index, object)
-- ECoreUtil.createFromString(type, (String)object)
-- XMLTypeFactoryImpl#createQNameFromString(type, val)
*** val is "xyz:myQName"
5. Now createQName("xyz:myQName")--
(i) simply checks if val startsWith "{" then it can resolve name space - which actually will never happen as
convertQNameToString() never appends targetNS to the
qnameLiteral (ii) in the else part - createQName(val) does nothing !
**** actually, in the else block it should extract the prefix and query the xmlnsPrefixMap to find the namespace and - then create a QName with the resolved namespace and literal.
6. -- So finally, user gets a qname without targetNS which breaks the
functionality of the system.
Please let me know the solution for this issue and correct me if I failed
to understand the QName resolution logic.
Is there any way I can extend / register XMLTypeFactory to override
createQName() ? or can I register my own Data Converter ?
thanks
Kaniska
P.S. - I have to use only emf 2.4.x.v200902171115
|
|
|
| Re: XMLTypeFactoryImpl fails to recreate QNames properly while "undoing change" [message #491049 is a reply to message #490996] |
Tue, 13 October 2009 03:49  |
Ed Merks
Messages: 33141
Registered: July 2009 |
Senior Member |
|
|
Kaniska,
Comments below.
Kaniska Mandal wrote:
> Hi All,
>
> problem description : I am using EMF .4.x.v200902171115 - to develop a
> tool and I see that QNames are not getting resolved properly when I
> undo my change !
>
> detail steps :
>
> 1. Lets assume : we have an EList mySpaces which hold a list of QNames
> -- persisted as
> <mydomain:myModel .. xmlns:xyz = "http://www/xyz.com/"
> <mydomain:mySpace horizon="xyz:myQName" /> ...
>
> 2. somewhere in system a RecordingCommand fires to clear the list of
> qnames-
> mySpacesEList.getHorizons().removeAll()
>
> 3. while removing the qname, emf prepares a List of changes and includes
> removed qname value in that list as follows ...
>
> -- ListChangeImpl#DataValueDelegatingList#
> -- new DelegatingEList() {
> -- validate(index, object)
> -- ECoreUtil.convertToString(type, object)
> -- XMLTypeFactoryImpl#convertQNameToString(type, instanceVal)
> *** now here instanceVal is a QName
> with targetNS =http://www/xyz.com/
> localpart=myQName
> prefix=xyz
> *** returns "xyz:myQName"
>
> ** here its important to note that emf does not append targetNS in the
> converted string !!
QNames unfortunately are an odd ball data type where only the prefix and
the local name are part of the value (the serializer relies on that
behavior), while the namespace is recorded elsewhere in the serialization...
>
> 4. Next, I undo my change from UI .. so emf tries to retrieve the saved
> changes and convert them back into relevant objects ..
>
> -- ListChangeImpl#DataValueDelegatingList#
> -- new DelegatingEList() {
> -- resolve(index, object)
> -- ECoreUtil.createFromString(type, (String)object)
> -- XMLTypeFactoryImpl#createQNameFromString(type, val)
> *** val is "xyz:myQName"
> 5. Now createQName("xyz:myQName")--
> (i) simply checks if val startsWith "{" then it can
> resolve name space - which actually will never happen as
> convertQNameToString() never appends targetNS to the
> qnameLiteral (ii) in the else part - createQName(val)
> does nothing !
Yes, I can imagine it working that way...
>
> **** actually, in the else block it should extract the prefix and
> query the xmlnsPrefixMap to find the namespace and - then create a
> QName with the resolved namespace and literal.
>
> 6. -- So finally, user gets a qname without targetNS which breaks the
> functionality of the system.
>
> Please let me know the solution for this issue and correct me if I failed
> to understand the QName resolution logic.
It sounds like an issue. I'm not sure what can be done about it;
special handling during the conversion step I suppose....
>
> Is there any way I can extend / register XMLTypeFactory to override
> createQName() ?
No, and changing that would break the serialization of QNames which
relies on the current behavior.
> or can I register my own Data Converter ?
No. Open a bugzilla and I'll try to find time to figure out what a good
solution might be.
>
> thanks
> Kaniska
>
> P.S. - I have to use only emf 2.4.x.v200902171115
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
|
|
|
|
|
| Re: XMLTypeFactoryImpl fails to recreate QNames properly while "undoing change" [message #491532 is a reply to message #491461] |
Wed, 14 October 2009 21:42 |
Ed Merks
Messages: 33141
Registered: July 2009 |
Senior Member |
|
|
Kaniska,
Comments below.
Kaniska Mandal wrote:
> Sure I should provide the testcase asap.
> Yah its true that actual issue boils down to - 'recording qname as
> string literal'
>
>
> Regarding proposed solution - what I meant is ..
>>> (1) say user created a qname with prefix "xyz"
>>> (2) then converttStringToQName(val) .. will have an argument -
>>> "xyz:myQname", (3) we can extract "xyz" from the argument ... and
>>> then >> (4) lookup xmlnsPrefixMap with the key "xyz" beause (5)
>>> xmlns:xyz "http://www.examples.com" is already persisted in the
>>> model and xmlnsPrefixMap [xyz:targetNS] is available through
>>> extendedMetaData.
>
> In case, the argument does not contain any nsPrefix, we won't have any
> targetNS as usual.
Well, an xmlns="xxx" declaration specifies a namespace for the
null/absent prefix, so I don't think this is true.
> But if the user provides a prefix while firsttime creating a qname ,
> he would expect that the namespace should be resolved from persisted
> metadata by using the prefix while reconstructing the qname.
What's the context in which this is occurring? How does the user know
what prefixes are available and what they map to? I'm not I understand
how this user issue relates to this specific issue...
>
> Please let me know if my understanding is correct.
>
> thanks
> kaniska
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Powered by
FUDForum. Page generated in 0.04869 seconds
] 
Search
Help
Register
Login
Home
