After re-reading my post and your response, I realized that my initial
thoughts on the issue were flawed to begin with. So if you had a difficult
time understanding or responding, it would be no wonder.
Allow me to recant.
All of the default naming conventions are actually fine with me. For some
reason, I had forgotten that explicitly defined / root complexType names
keep the name as is. And it is perfectly understandable that only anonymous
types would need a prefix or suffix, in order to avoid a naming collision
with their enclosing element definition, as you mentioned. So this would
explain why <jaxb:anonymousTypeName suffix="" prefix="" /> is NOT really
acceptable, since it would result in the same name as the enclosing element.
So, to summarize, please ignore what I said. 8-} And thanks for the
answer. I think it forced me to clarify and solidify all the issues in my
mind.
Brian Franklin
-----Original Message-----
From: Joe Fialli [mailto:Joseph.Fialli_at_Sun.COM]
Sent: Tuesday, May 27, 2003 11:27 AM
To: JAXB-INTEREST_at_JAVA.SUN.COM
Subject: Re: Discovered difference between JAXB 1.0 and beta
Franklin, Brian wrote:
>>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="" />
>
>
The default binding for mapping an XML complex type definition to a Java
interface name is the above, so this is not necessary.
> <jaxb:elementName suffix="Element" prefix="" />
> <!-- jaxb:modelGroupName left out because I have
not
>thought about defaults for it -->
> <jaxb:anonymousTypeName suffix="" prefix="" />
>
The above line should override the default suffix of "Type" for an
anonymous type definition that is
mapped to a Java interface or enum class. The intent of providing a
distinct symbol space for
anonymous types was to allow complete control over the name binding
conventions.
> </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).
>
I am uncertain if this was just a "naming conventions" problem or not.
Here is why one would want an Element
and a simple change to default naming is not sufficient.
In JAXB standard implementation 1.0, one can really only invoke
"Marshaller.marshal" or "Validator.validateRoot"
on an element.
Also, only an element can be checked whether it is nillable or not.
>
>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?
>
As mentioned above, this should work. However, not sure if this is just
a naming issue.
-Joe Fialli, Sun Microsystems
>
>
>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
>>
>>
>>
>>