Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » XML serialization and ns prefixes
XML serialization and ns prefixes [message #913452] Sat, 15 September 2012 17:52 Go to next message
Robert Brodt is currently offline Robert Brodt
Messages: 611
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
Re: XML serialization and ns prefixes [message #914978 is a reply to message #913452] Sun, 16 September 2012 06:04 Go to previous message
Ed Merks is currently offline Ed Merks
Messages: 26141
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
Re: XML serialization and ns prefixes [message #914983 is a reply to message #913452] Sun, 16 September 2012 06:04 Go to previous message
Ed Merks is currently offline Ed Merks
Messages: 26141
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
Re: XML serialization and ns prefixes [message #914991 is a reply to message #913452] Sun, 16 September 2012 06:04 Go to previous message
Ed Merks is currently offline Ed Merks
Messages: 26141
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
Re: XML serialization and ns prefixes [message #914998 is a reply to message #913452] Sun, 16 September 2012 06:04 Go to previous message
Ed Merks is currently offline Ed Merks
Messages: 26141
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
Re: XML serialization and ns prefixes [message #915004 is a reply to message #913452] Sun, 16 September 2012 06:04 Go to previous message
Ed Merks is currently offline Ed Merks
Messages: 26141
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
Previous Topic:Clear a resource with not null constraints
Next Topic:[CDO]
Goto Forum:
  


Current Time: Sat Oct 25 17:00:39 GMT 2014

Powered by FUDForum. Page generated in 0.02521 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software