>>From a technical perspective, I believe you solidly address the issue.
(Aside, I'm glad to see such technical foresight in anticipation of type
substitution -- a feature that I am personally anxiously awaiting)
May I propose solving the appearance / usability problem that Les has
described a different way. What if the defaults for the automatic naming
conventions for Type vs. Element were different? Specifically, what if the
defaults were the equivalent of the following customization:
<jaxb:schemaBindings>
<jaxb:nameXmlTransform>
<jaxb:typeName suffix="" prefix="" />
<jaxb:elementName suffix="Element" prefix="" />
<!-- jaxb:modelGroupName left out because I have not
thought about defaults for it -->
<jaxb:anonymousTypeName suffix="" prefix="" />
</jaxb:nameXmlTransform>
</jaxb:schemaBindings>
>>From what I understand, all the technical issues you (Joe) described below
would not present a problem. And from a code perspective, Les (and others,
of course) could go back to the more intuitive line:
Car car = garage.getCar();
After all, it's primarily the interface with which the developer must be
concerned, not whether or not it's an Element (although this could be
determined when necessary with a quick "instanceof", if the developer didn't
already know for sure from the situational context).
Perhaps I am forgetting some of the complex scenarios that undoubtedly exist
in the world of Schema Binding, particularly when looking ahead to more
advanced features like type and element substitution. If so, I'd love to
hear about them.
Oh, and I tried using that binding customization above, but suffix="" and
the like are not acceptable because an empty string doesn't count as an
NCName, according to the error message. So I can't override the default
"Type" suffix to remove it. Is there another way?
Thanks in advance for the discussion,
Brian Franklin
-----Original Message-----
From: Joe Fialli [mailto:Joseph.Fialli_at_Sun.COM]
Sent: Friday, May 23, 2003 11:14 AM
To: JAXB-INTEREST_at_JAVA.SUN.COM
Subject: Re: Discovered difference between JAXB 1.0 and beta
Kohsuke Kawaguchi wrote:
>Les Hazlewood <les_at_hazlewood.com> wrote:
>
>
>>In JAXB beta, I could do:
>>Car car = garage.getCar();
>>
>>Now, I can't do that....
>>
>>Instead, with JAXB 1.0 in the JWSDP, I have to do:
>>
>>CarType car = garage.getCar();
>>
>>I HATE this. Its incredibly unintuitive. Conceptually, I want to operate
>>on a CAR, not on a CarType.
>>
To support type substitution in the future and element substitution in
JAXB standard implementation 1.0.1
extension mode, it is mandatory that all getter signatures be specifed
as their Java representation for
the element's type definition, not the element's interface.
Type substitution mandates that JAXB java representations work with the
types of the elements,
not the actual element interfaces.
Given following XSD constraints:
Type Definition Hierarchy
Element
CarType
<xsd:element name="Car" type="CarType"/>
^
/ \ derivation by extension
/ \
DomesticCarType ForeignCarType
And the following valid XML document instances for these constraints:
<car> .....</car>
<car xsi:type="DomesticCarType"> ..domesticcartype content ... </car>
<car xsi:type="ForeignCarType"> ..foreigncartype content ... </car>
The method getCar() has to be able to return instances of ForeignCarType
and DomesticCarType, if complex type def CarType allows for type
substitution, which is the
default behavior in XSD. If getCar() returned a Car element, JAXB would
not be able to
easily support type suntitution in a future release.
For element substitution, consider the case of elements Car,
ForeignCar, and DomesticCar all belonging to the
same substitution group with Car being the head element. The method
setCar(CarType) works and accepts instances
of all elements in the substitution group since all elements are of
types that derive from CarType. This would not
work if setCar(Car value). Only the element instance Car could be passed
for this case. Other scenarios exist
in XSD where the "element" may not exist at all in the schema but the
xsi:type does and that is all that is necessary,
for example wildcard context processContents="lax".
By the way, the JAXB v1.0 specification does not mandate that the getter
return an instance of CarType or
one of the element instances of Car, ForeignCar and DomesticCar.
All the specification requires is that the returned instance implement
the interface for CarType.
If an element interface is generated for element Car, a JAXB
implementation could return an instance of Car element interface for the
above case.
As an optimization, JAXB tries to avoid generating Element interface
when they are not necessary, this
cuts down on the number of generated classes, especially when there is
one to many relationships between
a complex type definition and element declarations(with some being local
element declarations).
Thanks for your feedback.
-Joe Fialli, Sun Microsystems
>>
>>
>
>Well, I felt in the same way before. But the spec is clear on this, and
>therefore as an implementor I have no choice but to follow the spec.
>
>I think the rationale is that making it a CarType allows you to cut &
>paste that object into other places where a CarType is expected.
>
>And since Car is just extending a CarType without adding any significant
>method, I'm not so sure if it causes real pain in reality.
>
>But your input is very welcome. There might be even somethng we can do.
>
>
>regards,
>--
>Kohsuke KAWAGUCHI 408-276-7063 (x17063)
>Sun Microsystems kohsuke.kawaguchi_at_sun.com
>
>