[aloubyansky]

We do support binding to a model group. Model group can be referenced by its QName. This is what @JBossXmlModelGroup is for.

[aloubyansky]

The @XmlChild from some other part of the group
needs to replace the CDATA. The CDATA and subelements are mutually
exclusive. You can't have

<key class="java.lang.Integer">12
 <list ...>
</key>

It doesn't make sense. :-)

Ok, if that doesn't make sense we can throw an exception. My question is then does the following make sense? Not in the given MC example but in general. Can this be useful?

<wrapper attr="val1">
 <child ...>
</wrapper>
<wrapper attr="val2">
 <wildcard-content ...>
</wrapper>
<wrapper attr="val3">12</wrapper>

My point was it didn't matter what the content of wrapper was, the attr should still be set in the same way.

[adrian.brock]

We do support binding to a model group. Model group can be referenced by its QName. This is what @JBossXmlModelGroup is for.

I mean having a GroupBinding object inside JBossXB to which you can attach
processing rules.

The current strategy is to unwind any model into its components
sequences, choices, elements, etc.
which means there's no way for JBossXB to give me back the information
about where in the model I am when it does "setParent", etc.

You can see part of the problem with all the "instanceof" or "isModelGroup/Element"
etc. You have to bind to the unwound model rather than the real model and
hack around the "cognitive disonance" this causes. ;-)

[adrian.brock]

The @XmlChild from some other part of the group
needs to replace the CDATA. The CDATA and subelements are mutually
exclusive. You can't have

<key class="java.lang.Integer">12
 <list ...>
</key>

It doesn't make sense. :-)

Ok, if that doesn't make sense we can throw an exception. My question is then does the following make sense? Not in the given MC example but in general. Can this be useful?

<wrapper attr="val1">
 <child ...>
</wrapper>
<wrapper attr="val2">
 <wildcard-content ...>
</wrapper>
<wrapper attr="val3">12</wrapper>

My point was it didn't matter what the content of wrapper was, the attr should still be set in the same way.

With the current rules it will parse the attribute and set it on the CDATA type
(StringValueMetaData). But since there is no CDATA, it is child element
instead, the attribute will be discarded and the child type used e.g. ListValueMetaData.

We don't currently throw an exception for this. The spurious attribute is just ignored.

[aloubyansky]

adrian wrote:
With the current rules it will parse the attribute and set it on the CDATA type
(StringValueMetaData). But since there is no CDATA, it is child element
instead, the attribute will be discarded and the child type used e.g. ListValueMetaData.

We don't currently throw an exception for this. The spurious attribute is just ignored.

Yes, I understand this is what you need. But this, as a rule, looks very bizarre to me :) And I've been trying to make it more general hoping that it would make it less bizarre :) At least less bizarre to me and still do what you need :)

[adrian.brock]

Yes, I understand this is what you need. But this, as a rule, looks very bizarre to me :) And I've been trying to make it more general hoping that it would make it less bizarre :) At least less bizarre to me and still do what you need :)

It's bizarre because it is an ease of use thing.
A fairly common one I would imagine?

That is unless you want to piss off your users with verbose xml and
redundant elements just to be "correct". :-)

What is actually being done here is not something that xsd lets you express
directly.

Something like :-)

<type mixed="true">
 <choice>
 <element name="list"/>
 <element name="value"/>
 <cdata/>
...

[aloubyansky]

I am fine the structure of the schema. The bizarre thing is how it is treated during unmarshalling. I am for ease of use too and clarity. But I don't know what "correct" is :)

We need to set attributes on a node that don't belong to that node. Ok. What is confusing to me is why only on CDATA and not others?
Especially in the way you just wrote the schema: the cdata is a node on the same level as other elements. Why the attribute is lost on others?

All I want to know is whether there is any other reason than "I don't need it in my example"?

[adrian.brock]

I am fine the structure of the schema. The bizarre thing is how it is treated during unmarshalling. I am for ease of use too and clarity. But I don't know what "correct" is :)

We need to set attributes on a node that don't belong to that node. Ok. What is confusing to me is why only on CDATA and not others?
Especially in the way you just wrote the schema: the cdata is a node on the same level as other elements. Why the attribute is lost on others?

All I want to know is whether there is any other reason than "I don't need it in my example"?

Because that isn't what is happening. It's probably easier to see with the
property parsing.

I'll repeat everything again, because although you say you understand
you don't seem to be getting the key point. ;-)

<property name="blah" replace="false">x</property>

Is really in our underlying model

<property name="blah"><value replace="false">x</value></property>

The user can write it the long way if they want, but we give them the "short form" version.

In this case, we've got a specific type we can store the "replace" on,
so we don't need the wrapper hack because we can do it in our @XmlValue method.

In the generic case (like the map's key/value) we don't have this option so we need
to "synthesize it" during the parsing.

i.e. it goes something like:

<map> new AbstractMapMetaData
 <entry> new MapEntry
 <key> new StringValueMetaData (SVMD)
 <list> oops not CDATA discard the SVMD and use AbstractListValueMetaData

We need to put the SVMD in place early otherwise we've got nothing to set
the attributes on (if there are any).
This is an artifcat of attributes are processed being processed
before the CDATA in the parsing.

NOTE: There really aren't any attributes on "key"
in our real model. They exist on the key in the xml just for ease of use.

Key isn't even a type it's a property of MapEntry which accepts an interface
which maps in xml to a group of posslble values including the synthetic
SVMD wrapping the CDATA.

[adrian.brock]

In the generic case (like the map's key/value) we don't have this option so we need
to "synthesize it" during the parsing.

I guess an alternative would be to create more parsing artifacts,
something like:

public class MapEntry
{
 public Holder key;
 public Holder value;
}

@BeanAdapter(HolderAdapterFactroy.class)
public class Holder
{
 @XmlAttribute(name="replace")
 boolean replace;

 ValueMetaData value;

 @XmlValue
 public String string;

//etc.
}

Then write some code in HolderAdapter.getValue() that tries to figure out what to return
based on what to do based on what has been set.

But this isn't very declarative and is only usable in the MC's map context
rather than generically when others hit the same/similar problem.

It's also a lot more code to write and maintain. :-)