[jason.greene]

Or different schemas need to be associated with the same object model.
-Jason

Yes, this is also broken as well. :-)

The namspace is associated with the
package level annotation rather the root element.
This is a basic reusability issue.

The package level namespace declaration in JAXB is just a default value for convenience purposes. You can specify the namespace on XmlType and XmlRootElement.

What I meant is that the you can't have both the ejb2.1 schema and ejb3 schema map to the same objects.

-Jason

[starksm64]

Either way the mapping of namespace to classes has to be known before unmarshalling, the difference is that you can lazy load classes with JBossXB. If lazy discovery is important, we should get involved with the spec and get it added.

The more immeadiate question is whether getting involved with jaxb to get jbossxb features into it is worth while.

The issue with a mapping like this is that if there is any similarity between the types that could be present on a wildcard, then using schema subtyping is more appropriate.

I don't see how that resolves the problem. That just introduces a common base schema type for the interface, but it still has a wildcard because the implementation details are outside of the contract. This is a common issue with a plugin architecture.

[weston.price]

The more immeadiate question is whether getting involved with jaxb to get jbossxb features into it is worth while.

There are a lot of specs that I think we should be involved in (ie JDBC etc) and this is one of them. Time constraints notwithstanding, I think it's important to get our voice/participation. I hate the NIH syndrome and I think we fall prey to it more often than not.

[starksm64]

The more immeadiate question is whether getting involved with jaxb to get jbossxb features into it is worth while.

There are a lot of specs that I think we should be involved in (ie JDBC etc) and this is one of them. Time constraints notwithstanding, I think it's important to get our voice/participation. I hate the NIH syndrome and I think we fall prey to it more often than not.

The spec is not the issue though. Its clearly under defined for our legacy usecases. I'm more interested in implementation first, spec second.

[weston.price]

That's fine, and I many ways I agree with you. However, my next question would be how many legacy use cases do we really have, and more importantly, are there enough cases to develop an entire in-house, non-standard binding framework to handle 2%, 5%?

[starksm64]

Yes, its the plethora of legacy dtds, as well as features like the wildcard issue. We should be looking first to get support for these in the jaxb project as extensions, and then worry about what can be standarized.

[weston.price]

+1

Well said.

[jason.greene]

Either way the mapping of namespace to classes has to be known before unmarshalling, the difference is that you can lazy load classes with JBossXB. If lazy discovery is important, we should get involved with the spec and get it added.

The more immeadiate question is whether getting involved with jaxb to get jbossxb features into it is worth while.

I definately can't say, but my guess is that its not necessary at this point. since so much is built on JBossXB. However, longer term it should be looked at IMO.

The issue with a mapping like this is that if there is any similarity between the types that could be present on a wildcard, then using schema subtyping is more appropriate.

I don't see how that resolves the problem. That just introduces a common base schema type for the interface, but it still has a wildcard because the implementation details are outside of the contract. This is a common issue with a plugin architecture.

It doesn't. I was looking at it from the perspective of how a general xml binding framework should work. Mapping a wildcard to an interface, or common subtype adds restrictions that aren't represented in the schema definition. So Object (or some binding based wildcard java type) is a more natural container for a schema wildcard. However, I can see where being able to add your own generic wildcard type would simplify the programming model.

[adrian.brock]

Update:

I've written a simple JAXB unmarshalling implementation over JBossXB
so it is a sort of half-way house solution.

JAXB annotations with JBossXB

http://www.jboss.com/index.html?module=bb&op=viewtopic&t=101041

The advantages are:

1) We don't have to choose a JAXB implementation which gets forced on the users.

2) We can fix the bugs when there is a problem (my version doesn't have
the bug reported above - although it probably has others :-)

3) We can implement new stuff/features like dtd support which is going to
be pretty difficult to get into the spec/RI.

[adrian.brock]

Of course we can eventually push these features back into the spec,
but we don't have to hold our breaths when we need something important.