Re: [mdr-users] XMI Modules supported by MDR?

Pieter and Martin,

"It is obvious that this will end up with an error, since the file 
referenced from the hrefs is a binary file, not a valid XML."  That's 
precisely why we had to create our MDRXmiReferenceResolverContext class 
that resolves that Magic Draw xml.zip into the full XMI path..  Pieter,  
have you taken a look at the source in the andromda-all/repositories/mdr 
module?  That should help you get the XMI hrefs working with Magic Draw 
(we're using the latest MDR builds and things work fine).

Martin Matula wrote:

> Pieter,
> modelWithModules.xml contains hrefs of a proprietary format - they 
> reference zip file - MDR tries to handle files referenced in HREFs as 
> XML files, since that's how standard hrefs in XMI should work. By 
> trying to parse the file referenced from HREF - i.e. the zip file - 
> the XML parser seems to report this weird message (we are using the 
> standard XML parser that is part of the JDK - MDR sources themselves 
> do not contain any string literal containing word "prolog" so the 
> message is really not generated by MDR). It is obvious that this will 
> end up with an error, since the file referenced from the hrefs is a 
> binary file, not a valid XML.
> Regards,
> Martin
>
> Pieter Van Gorp wrote:
>
>> Hi all,
>> coming back to a recent thread, I have prepared a small example that
>> illustrates the problem I experienced with MDR.
>>
>> On http://www.fots.ua.ac.be/~pvgorp/tmp/mdr/ you find
>> modelWithoutModules.xml and modelWithModules.xml.  The former is an
>> XMI file exported by MagicDraw 9.0 that is correctly processed by MDR.
>> The latter represents the same UML model but imports profile
>> information from an external XMI module file called
>> sdm-profile-jcmtg.xml.zip.  Apart from storing the profile in a
>> separate file, there should be no changes between modelWithModules.xml
>> and modelWithoutModules.xml.  MDR throws the "content not allowed in
>> prolog" exception when loading modelWithModules.xml.
>>
>> If you like to execute the problematic situation on your machine, you
>> can use the code from mdr-modules.tar.gz.  The reason for the large
>> file size is that I wanted to make the code executable with minimal
>> effort for me and you ;-) Once unzipped, go to the
>> mdr-modules/jcmtg/transformer dir and execute (1) ant build-exec, (2)
>> ant and (3) ant exec.
>>
>> You can switch between the loading of modelWithModules.xml and
>> modelWithoutModules.xml by adjusting the trans.model.xmi.url property
>> in mdr-modules/jcmtg/transformer/build.properties.
>>
>> Chad, I tried to use plain XML files only instead of zipped XML files
>> and I still get the exception, so I'm not sure if using a custom XMI
>> reference resolver will solve the problem.
>>
>> I hope if these sample files help you understand my problem better. 
>> Please let me know if I should give additional info.
>>
>> Best regards,
>> Pieter.
>>
>> On 6/15/05, Pieter Van Gorp <[email protected]> wrote:
>>  
>>
>>> Hi Martin, I'll check out Chad's solution first and send my files if
>>> that doesn't work for me.
>>>
>>> Thanks again,
>>> Pieter.
>>>
>>> On 6/14/05, Martin Matula <[email protected]> wrote:
>>>   
>>>
>>>> A minimal example would of course be more desirable. Anyway, if your
>>>> files are of a reasonable size for sending them to the mailing list, I
>>>> don't mind...
>>>>
>>>> Pieter Van Gorp wrote:
>>>>
>>>>     
>>>>
>>>>> Hi Martin,
>>>>> shall I post to the list my actual MagicDraw XMI files (profile
>>>>> definition and application) or shall I make a minimal example that
>>>>> still triggers the exception first?
>>>>>
>>>>> Regards,
>>>>> Pieter.
>>>>>
>>>>> On 6/14/05, Pieter Van Gorp <[email protected]> wrote:
>>>>>
>>>>>
>>>>>       
>>>>>
>>>>>> Hi Martin,
>>>>>> thanks for your reply:
>>>>>>
>>>>>> On 6/14/05, Martin Matula <[email protected]> wrote:
>>>>>>
>>>>>>
>>>>>>         
>>>>>>
>>>>>>>> I'm experiencing problems when processing XMI files using external
>>>>>>>> modules in MDR.  My input file is a UML file in XMI generated by
>>>>>>>> MagicDraw 9.  The problem occurred after moving my profile 
>>>>>>>> definitions
>>>>>>>> to a separate XMI file.  MDR throws a "Content is not allowed in
>>>>>>>> prolog" exception.
>>>>>>>>
>>>>>>>>
>>>>>>>>             
>>>>>>>
>>>>>>> That's weird. MDR definitely does not print anything like that. 
>>>>>>> Maybe
>>>>>>> the XML parser does that. Try if the file is a valid XML.
>>>>>>>
>>>>>>>
>>>>>>>           
>>>>>>
>>>>>> Here's the context of the exception:
>>>>>> org.netbeans.lib.jmi.util.DebugException: Content is not allowed 
>>>>>> in prolog.
>>>>>>       at 
>>>>>> org.netbeans.lib.jmi.xmi.XmiContext.readExternalDocument(XmiContext.java:927) 
>>>>>>
>>>>>>
>>>>>> When validating with Xerces, I get a lot of "undeclared type" errors
>>>>>> although MagicDraw happily opens and saves the file...
>>>>>>
>>>>>>
>>>>>>
>>>>>>         
>>>>>>
>>>>>>>> I found that AndroMDA contains special code for dealing with 
>>>>>>>> modules
>>>>>>>> (in the 
>>>>>>>> org.andromda.repositories.mdr.MDRXmiReferenceResolverContext
>>>>>>>> class).  Should I follow the same strategy or does MDR provide
>>>>>>>> built-in module-support such that I don't have to wrap repository
>>>>>>>> classes?  For instance, is there one specific MDR method that I 
>>>>>>>> should
>>>>>>>> call after loading an XMI file containing hrefs to elements in 
>>>>>>>> another
>>>>>>>> XMI file to make MDR treat the two XMI files as one large model?
>>>>>>>>
>>>>>>>>
>>>>>>>>             
>>>>>>>
>>>>>>> MDR does this automatically.
>>>>>>>
>>>>>>>
>>>>>>>           
>>>>>>
>>>>>> Good to know... it makes me wonder why AndroMDA uses special XMI
>>>>>> resolvers... anyway, I'm still wondering where the "content is not
>>>>>> allowed in prolog" exception comes from...
>>>>>>
>>>>>>
>>>>>>
>>>>>>         
>>>>>>
>>>>>>> In earlier versions of MagicDraw there was
>>>>>>> a bug in XMI serialization causing CompositionViolationException. I
>>>>>>> don't know if this was fixed in MagicDraw 9, but so far this 
>>>>>>> does not
>>>>>>> seem to be your problem.
>>>>>>>
>>>>>>>
>>>>>>>           
>>>>>>
>>>>>> Indeed, in fact I encountered this problem when copying subgraphs
>>>>>> across models.  It was not a bug of MagicDraw but a consequence 
>>>>>> of my
>>>>>> way of copying model elements.  I'll come back to that shortly.
>>>>>>
>>>>>> Best regards,
>>>>>> Pieter.
>>>>>>
>>>>>>
>>>>>>
>>>>>>         
>>>>>
>>>>     
>>>
>
>