[ https://issues.jboss.org/browse/DROOLS-2578?page=com.atlassian.jira.plugi... ] Michael Anstis commented on DROOLS-2578: ---------------------------------------- [~tari_manga] Yes, that is correct (and not just the top-level conversion, but also for example an Expression in a ContextEntry in a Context needs the parent chain established) - so not just setting the parent in the Context etc but also any children that are created as part of the conversion. I use the parent information to resolve QNames for data-types on, for example, InformationItems. The XML (v1.1) has, for example feel:String and I need to verify "feel" is indeed the FEEL NameSpace (i.e. URL) in case a User has either used something different for FEEL NameSpace alias (so, for example the data-type might be mynamespace:String where mynamespace is the prefix for FEEL URL). Does this make sense? I'd be interested to know/understand how this is handled in v1.2. [~tari_manga] IF the editor is to support v1.2 on launch then the work for this JIRA may become obsolete very quickly and hence not worth doing.. feel (ha!) free to check with [~tirelli] as to whether we need worry about it too much (at the moment if I cannot resolve the prefix on the DMN node - e.g. Decision, ContextEntry, InformationItem etc - I simply look in the Definitions. It surely must be an edge case to think a User has (re-)defined a NameSpace prefix within the DMN object hierachy (e.g. prefix "feel" is FEEL URL in Definitions, but FEEL URL is redefined as mynamespace within an intermediate object - between Definitions and for example an Expression on a ContextEntry in a Context in a Decision. -- This message was sent by Atlassian JIRA (v7.5.0#75005)