JiBX

binding compiler: xmlns="" not supported

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Won't Fix
  • Affects Version/s: JiBX 1.1
  • Fix Version/s: None
  • Component/s: core
  • Labels:
    None
  • Environment:
    Windows XP Pro, Java JDK 1.4.2
  • Testcase included:
    yes
  • Number of attachments :
    0

Description

Synopsis of the problem:

globals.xsd:
<xs:schema xmlns="globals" targetNamespace="globals" elementFormDefault="unqualified">
<xs:simpleType name="idType">
<xs:restriction base="xs:string"/>
</xs:simpleType>
</xs:schema>

NOTE: The issue hinges on the elementFormDefault being set to unqualified.

request.xsd:
<xs:schema xmlns="request" targetNamespace="request" xmlns:g="globals" elementFormDefault="qualified">
<xs:import namespace="globals" schemaLocation="globals.xsd"/>
<xs:element name="req">
<xs:complexType>
<xs:sequence>
<xs:element name="id" type="g:idType"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>

request.xml:
<?xml version="1.0" encoding="UTF-8"?>
<req xmlns="request">
<id xmlns="">123</id>
</req>

binding.xml
<binding xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="binding.xsd">
<mapping name="req" class="...">
<namespace uri="request" default="elements"/>
<value name="id" field="id" ns=""/>
</mapping>
</binding>

When I try running the binding compiler against this binding, I receive the following error:

Running binding compiler version jibx_1_1
Error running binding compiler

      • Error during code generation - please enter a bug report for this error in Jira if the problem is not listed as fixed on the online status page ***

org.jibx.runtime.JiBXException: Undefined or unusable namespace ""
at org.jibx.binding.def.NameDefinition.fixNamespace(NameDefinition.java:143)
at org.jibx.binding.def.BindingBuilder.unmarshalValue(BindingBuilder.java:553)
at org.jibx.binding.def.BindingBuilder.unmarshalStructureChildren(BindingBuilder.java:848)
at org.jibx.binding.def.BindingBuilder.unmarshalMapping(BindingBuilder.java:1651)
at org.jibx.binding.def.BindingBuilder.unmarshalMappings(BindingBuilder.java:983)
at org.jibx.binding.def.BindingBuilder.unmarshalBindingDefinition(BindingBuilder.java:1837)
at org.jibx.binding.Utility.loadBinding(Utility.java:293)
at org.jibx.binding.Utility.loadFileBinding(Utility.java:413)
at org.jibx.binding.Compile.compile(Compile.java:296)
at org.jibx.binding.Compile.main(Compile.java:385)

I tried running xsd2jibx against the schema to see what code it would generate and it produced a binding.xml without the ns="" attribute. However, this would cause the sample.xml provided to generate an error when parsing since it JiBX thinks the <id> tag should be a part of the request namespace.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Andy Biewer added a comment -

Pardon my ignorance, but I just figured out that you can create multiple <namespace>'s under a <mapping> including the empty namespace.

This tool is profoundly powerful! Thank you.

Show
Andy Biewer added a comment - Pardon my ignorance, but I just figured out that you can create multiple <namespace>'s under a <mapping> including the empty namespace. This tool is profoundly powerful! Thank you.
Hide
Permalink
Todd Dunst added a comment -

One might wonder why you would want to to use elementFormDefault unqualifed for a (presumably) global element/type definitions. If the global elements/types are destined to be reused by a more specific schema (in your case the request schema), then you are forcing the consumers of your schemas to place elements in they're instance documents in the empty/none/null namespace (i.e. xmlns="") as you are explicitly forbidding them to qualify the element definitions. At a minimum this would potentially open up any such element/type definitions to namespace collisions with other elements defined in the empty namespace to say nothing of the fact that it is extremely confusing for consumers of the schemas to have to understand that in order to get they're instance documents to validate against your schema, they actually have to place elements in they're instance documents (at least those derived from you global schema) in the empty xmlns="" namespace. At worst, your will run into problems like this, where specific schema binding technologies like Jib-X will run into difficultly attempting to bind to your schema definitions as they are unable to successfully create the xmlns="" element overrides.

My suggestion would be to simply change your global schema to use the elementFormDefault qualifed option. This way, your global element/type definitions would be differentiated from other global element/type definitions, and your schemas would be more widley consumable 'out-of-the-box' by a wider varitey of OXM technologies.

As a side note, did you ever get Jib-X to generate the xmlns="" namespace override? If so, I would really like to see you binding file.

Show
Todd Dunst added a comment - One might wonder why you would want to to use elementFormDefault unqualifed for a (presumably) global element/type definitions. If the global elements/types are destined to be reused by a more specific schema (in your case the request schema), then you are forcing the consumers of your schemas to place elements in they're instance documents in the empty/none/null namespace (i.e. xmlns="") as you are explicitly forbidding them to qualify the element definitions. At a minimum this would potentially open up any such element/type definitions to namespace collisions with other elements defined in the empty namespace to say nothing of the fact that it is extremely confusing for consumers of the schemas to have to understand that in order to get they're instance documents to validate against your schema, they actually have to place elements in they're instance documents (at least those derived from you global schema) in the empty xmlns="" namespace. At worst, your will run into problems like this, where specific schema binding technologies like Jib-X will run into difficultly attempting to bind to your schema definitions as they are unable to successfully create the xmlns="" element overrides. My suggestion would be to simply change your global schema to use the elementFormDefault qualifed option. This way, your global element/type definitions would be differentiated from other global element/type definitions, and your schemas would be more widley consumable 'out-of-the-box' by a wider varitey of OXM technologies. As a side note, did you ever get Jib-X to generate the xmlns="" namespace override? If so, I would really like to see you binding file.
Hide
Permalink
Andy Biewer added a comment -

You seem to be implying that we had the time to even think about these issues while we were building this application from the ground up in 3 months. As it were, the project was under very compressed timelines and, being what it is, this is what happened. Albeit, not a good choice, but it is what it is.

And yes, I did get it to work, as I stated in my comment above. For example:

<mapping name="Org" class="orgLst.Org">
<namespace uri="prodDtlInqReq" default="elements"/>
<namespace uri="" prefix="xyz"/>
<value name="OrgID" set-method="setOrgID" get-method="getOrgID" ns=""/>
</mapping>

BTW, "they're" should be "their".

Show
Andy Biewer added a comment - You seem to be implying that we had the time to even think about these issues while we were building this application from the ground up in 3 months. As it were, the project was under very compressed timelines and, being what it is, this is what happened. Albeit, not a good choice, but it is what it is. And yes, I did get it to work, as I stated in my comment above. For example: <mapping name="Org" class="orgLst.Org"> <namespace uri="prodDtlInqReq" default="elements"/> <namespace uri="" prefix="xyz"/> <value name="OrgID" set-method="setOrgID" get-method="getOrgID" ns=""/> </mapping> BTW, "they're" should be "their".

People

  • Assignee:
    Unassigned
    Reporter:
    Andy Biewer
Vote (0)
Watch (2)

Dates

  • Created:
    Updated:
    Resolved: