On Tue, Mar 15, 2011 at 10:28 PM, Dennis Sosnoski <d...@sosnoski.com> wrote:
> First, there doesn't seem to be any reason why you can't use type-names
> with substitution groups (i.e., extends="typename"). This seems like a
> relatively simple limitation that could be fixed in the JiBX parsing engine.
> In other words, you should be able to do this:
>
> <mapping abstract="true" class="com.example.Vehicle" type-name="vehicle">
> <mapping class="com.example.Car" name="Car" extends="vehicle">
> <mapping class="com.example.Truck" name="Truck" extends="vehicle">
>
>
> True in principle, but if you're modeling substitution groups you still
> need a name attached to the base <mapping>.
>
I don't understand what you're saying... isn't "vehicle" just as good a name
as "com.example.Vehicle"? Obviously I'm still missing something.
>
> Next issue: requiring concrete mappings with substitution groups. With
> substitution groups, somewhere you have to specify the set of valid XML tags
> (and corresponding Java classes) that are allowed for the group. Call this
> the "group specification'. With the current JiBX, the concrete mappings
> implicitly provide the group specification -- and I'm guessing that's
> probably the main reason why they are required.
>
> But it might be simpler and more modular if the "group specification" was
> declared explicitly at the point of use. This would then allow us to relax
> the requirement for concrete mappings. For example:
>
> <mapping abstract="true" class="com.example.Vehicle" type-name="vehicle">
> <mapping abstract="true" class="com.example.Car" type-name="car"
> extends="vehicle">
> <mapping abstract="true" class="com.example.Truck" type-name="truck"
> extends="vehicle">
> ...
> <mapping abstract="true" class="com.example.FooBar" type-name="fooBar">
> <structure field="vehicle">
> <mapping-option name="Car" map-as="Car"/>
> <mapping-option name="Truck" map-as="Trunk"/>
> </structure>
> ...
>
> What I like about this is that it's much clearer from looking at the
> mapping file what can happen. This also could even be implemented so that it
> was backward compatible with existing mapping files.
>
>
> Here again, if you're modeling substitution groups each element in the
> group must be declared as a global element in the schema definition. So
> although it would be possible to have a binding definition separately
> declare the element names you'd still need a global <mapping> for each one.
> There's also the issue that substitution groups may involve multiple levels
> of definitions. But the biggest objection I'd have to this approach is that
> you'd need to duplicate the whole structure anywhere you used a Vehicle
> reference. Given these issues, I'm not convinced it'd be worth the effort
> the change from the current approach where the names and the substitution
> group relationship are both declared in the <mapping>.
>
I agree about the duplication problem...
But I think the desire to synchronize JiBX mapping files with XSD structure
is in fact what adds complexity (and confusion), at least in the current
incarnation. I suppose it's a good goal overall, but if so then there is
probably a clearer way to do it. For example, why not define the
substitution group explicitly, all in one place using a <substitution-gropu>
element, and then reference it by name when needed, instead having it
implicitly defined by the individual <mapping> elements.
But more generally, requiring that anything expressible using a JiBX mapping
be also expressible via XSD seems like an unfortunate limitation. E.g., you
could instead just have a rule of the form "if you want to generate an XSD
file, you are limited to these rules/constructs in your JiBX mapping file".
In other words the fact that XSD requires substitution groups to be
top-level is just kindof dumb, but if I'm not generating an XSD file, it
shouldn't cause me to have to make all my <mapping>'s global, etc.
-Archie
--
Archie L. Cobbs
------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
_______________________________________________
jibx-users mailing list
jibx-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jibx-users
