[aloubyansky]

maybe fork a prototype (in the testsuite) in the process so I don't break JBossWS? :-)

That means you are going to work in parallel on some issues that are not in my plan and then merge back? How are you going to manage/maintain this? Implementation details are not very stable currently and, actually, are going to change. So far, I don't like the idea and would prefer to discuss and create issues.

[aloubyansky]

I was thinking of something like this?

 <xsd:complexType name="datasourceType">
 <xsd:appinfo>
 <!-- new DataSourceConfig() -->
 <jbxb:class impl="org.jboss.xxx.DataSourceConfig">
 <!-- DataSourceConfig.setPoolConfig(new PoolConfig()) -->
 <jbxb:holder name="pool" property="poolConfig" impl="org.jboss.xxx.PoolConfg"/>
 </jbxb:class>
 </xsd:appinfo>
 </xsd:annotation>
 <xsd:choice>
 <xsd:element name="maxsize">
 <xsd:annotation>
 <xsd:appinfo>
 <!-- poolConfig.setMaxSize(...) -->
 <jbxb:property holder="pool" name="maxSize"/>
 </xsd:appinfo>
 </xsd:annotation>
 </xsd:element>
 </xsd:choice>
 </xsd:complexType>

Which could also be written like this?

 <xsd:element name="maxsize">
 <xsd:annotation>
 <xsd:appinfo>
 <!-- poolConfig.setMaxSize(...) -->
 <jbxb:property path="poolConfig.maxSize"/>
 </xsd:appinfo>
 </xsd:annotation>
 </xsd:element>

I agree, maxsize could be set differently (in other words, the path could be different) based on the current object on the stack. That's what I was talking about a few posts ago about setting value on the parent in the parent's specific way.

[aloubyansky]

In that case, jbxb:property could also have a 'class' attribute and be applied only if the type of the current object on the stack is assignable from the one specified in the 'class' attribute.

[aloubyansky]

It should be getting a StringValueMetaData. But it actually gets a can't load class "org.jboss.test.xml.pojoserver.metadata.ValueType"
It shouldn't really try to instantiate something here because the type is going to
come from the contained valueGroup (polymorphically).

Check this out. It seems like the way to go.
http://www.w3.org/TR/xmlschema-0/#abstract

[adrian.brock]

Also some schema issues. You define entry type

Yes. That is a mistake.

[adrian.brock]

maybe fork a prototype (in the testsuite) in the process so I don't break JBossWS? :-)

That means you are going to work in parallel on some issues that are not in my plan and then merge back? How are you going to manage/maintain this? Implementation details are not very stable currently and, actually, are going to change. So far, I don't like the idea and would prefer to discuss and create issues.

Thats ok. I don't expect you to support it. I'm just playing with ideas.
See my other thread where I created a schema parser that can be more easily extended.
It also has the sideaffect that it doesn't depend on Xerces.

[adrian.brock]

In that case, jbxb:property could also have a 'class' attribute and be applied only if the type of the current object on the stack is assignable from the one specified in the 'class' attribute.

I think you missed the point here. The target object isn't necessarily on the stack.
Or it might be on the stack but further back.

The structure of the xml and classes are not in 1-1 correspondance.

[adrian.brock]

It should be getting a StringValueMetaData. But it actually gets a can't load class "org.jboss.test.xml.pojoserver.metadata.ValueType"
It shouldn't really try to instantiate something here because the type is going to
come from the contained valueGroup (polymorphically).

Check this out. It seems like the way to go.
http://www.w3.org/TR/xmlschema-0/#abstract

Agreed, we should use the XSD type system rather than using a predefined group.
This allows others to extend the schema and introduce their own subtype.

[starksm64]

A related discussion:
http://www.xml.com/pub/a/2003/10/29/derivation.html