Eclipse Community Forums: EMF » XML serialization and ns prefixes

Help

Home

Home » Modeling » EMF » XML serialization and ns prefixes

Show: Today's Messages :: Show Polls :: Message Navigator

XML serialization and ns prefixes [message #913452]

Sat, 15 September 2012 17:52

Robert Brodt

Messages: 811
Registered: August 2010
Location: Colorado Springs, CO

Senior Member

Hi all,

I'm running into a problem with serialization and parsing XML when a Resource includes elements from two different models. I have the following XML fragment that contains elements from two different EMF models, "bpmn2" and "drools":

<bpmn2:definitions
	xmlns:bpmn2="http://www.omg.org/spec/BPMN/20100524/MODEL"
	xmlns:drools="http://www.jboss.org/drools"
	targetNamespace="http://www.jboss.org/drools">
	<bpmn2:process id="process_1" drools:version="1" name="Default Process">
		<bpmn2:extensionElements>
			<drools:global drools:identifier="globalVar123" drools:type="String" />
		</bpmn2:extensionElements>

The BPMN2 editor can deal with this just find and life is good. Unfortunately, the consumer of this model (the jBPM runtime engine) does not handle the "drools" namespace prefixes very well for the <drools:global> element. It would rather see something like this instead:

			<drools:global identifier="globalVar123" type="String" />

In other words, all features of "drools" model elements may not be qualified with a ns prefix. Oddly enough, this is not an issue with the "drools:version" attribute in the <bpmn2:process> element.

With some experimentation of loader options, I discovered that setting XMLResource.OPTION_LAX_FEATURE_PROCESSING to TRUE will successfully parse the modified XML, but there's still the problem of serializing the model: the "drools" ns prefixes are always added again.

My question: is there a serializer option that prevents these prefixes from being added to attributes? Is there another way to get around this?

BTW, the ExtendedMetaData for the "identifier" and "type" attributes includes "namespace=##targetNamespace".

Thanks!
Bob

Report message to a moderator

Re: XML serialization and ns prefixes [message #914978 is a reply to message #913452]

Sun, 16 September 2012 06:04

Ed Merks

Messages: 33137
Registered: July 2009

Senior Member

Robert,

Comments below.

On 15/09/2012 7:52 PM, Robert Brodt wrote:
> Hi all,
>
> I'm running into a problem with serialization and parsing XML when a
> Resource includes elements from two different models. I have the
> following XML fragment that contains elements from two different EMF
> models, "bpmn2" and "drools":
>
>
> <bpmn2:definitions
> xmlns:bpmn2="http://www.omg.org/spec/BPMN/20100524/MODEL"
> xmlns:drools="http://www.jboss.org/drools"
> targetNamespace="http://www.jboss.org/drools">
> <bpmn2:process id="process_1" drools:version="1" name="Default
> Process">
> <bpmn2:extensionElements>
> <drools:global drools:identifier="globalVar123"
> drools:type="String" />
> </bpmn2:extensionElements>
>
>
> The BPMN2 editor can deal with this just find and life is good.
> Unfortunately, the consumer of this model (the jBPM runtime engine)
> does not handle the "drools" namespace prefixes very well for the
> <drools:global> element. It would rather see something like this instead:
>
>
> <drools:global identifier="globalVar123" type="String" />
>
>
> In other words, all features of "drools" model elements may not be
> qualified with a ns prefix. Oddly enough, this is not an issue with
> the "drools:version" attribute in the <bpmn2:process> element.
>
> With some experimentation of loader options, I discovered that setting
> XMLResource.OPTION_LAX_FEATURE_PROCESSING to TRUE will successfully
> parse the modified XML, but there's still the problem of serializing
> the model: the "drools" ns prefixes are always added again.
>
> My question: is there a serializer option that prevents these prefixes
> from being added to attributes? Is there another way to get around this?
>
> BTW, the ExtendedMetaData for the "identifier" and "type" attributes
> includes "namespace=##targetNamespace".
Yes, that's the problem. This tells the serializer that it's supposed
to qualify the XML serialization with the target namespace and expect
that upon deserialization. Probably that's what the schema itself
declares is a correct serialization so it should be respected to have a
conforming serialization.
>
> Thanks!
> Bob

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator