On Tue, Jan 5, 2010 at 1:55 AM, Adam Zell <zellster_at_gmail.com> wrote:
> Greetings,
>
> On Mon, Jan 4, 2010 at 1:31 AM, Wolfgang Laun <wolfgang.laun_at_gmail.com>wrote:
>
>> On Mon, Jan 4, 2010 at 9:59 AM, Pavel Bucek <Pavel.Bucek_at_sun.com> wrote:
>>
>>> Hello,
>>>
>>> actually, I remember committing this change and as Wolfgang wrote, this
>>> was made to align reference implementation with specification - this is a
>>> bug in versions <2.2.
>>>
>>> So that means you use invalid (from JAXB perspective) namespace
>>> declaration.
>>>
>>
>> Hmm, I'd say it's a valid URI (at least as far as I understand the RFC),
>> and
>> the Spec doesn't prohibit using the segment part; it's just that JAXB has
>> to
>> convert '#' as it can't be in a package name.
>>
>> (Whether or not using a segment part should/could/might result in a
>> subpackage would
>> be interesting to discuss, but that's perhaps a rather philosphical
>> issue.)
>>
>> Given the change in behavior from xjc 2.1.12 to 2.2, is it then
> recommended not to use an anchor in a namespace URI?
>
If you want to avoid the change in the resulting package names: yes.
(Although, a simple XSLT could be used to modify the URI before you compile:
either s/#/_/ before calling 2.1.12 or s/#.*$// before calling 2.2.)
> I can't easily find where the anchor violates the specification. Is
> there a link available? The only thing I found was at
> http://www.w3.org/TR/REC-xml-names/#dt-NSDecl. Nothing in the document
> appeared to disallow #23.
>
> If dealing with a legacy schema with a hash character in the namespace, is
> there any option that could be placed in an .xjb file to coerce 2.2 xjc?
>
No, but surely you control the build process? Or check the xjc version by
calling xjc -version and checking the output.
-W
> Thanks!
>
>
>> -W
>>
>>
>>>
>>> Pavel
>>>
>>> Wolfgang Laun wrote:
>>>
>>>> Hi Adam,
>>>>
>>>> please check the results as you posted them in relation to the
>>>> xjc version. Your post would indicate that the newest xjc drops
>>>> the URI fragment part entirely, as opposed to 2.1.12.
>>>>
>>>> There is indeed a difference between 2.2 and earlier versions,
>>>> but I find that 2.2 does the right thing, i.e., according to the
>>>> JAXB specification, section D.5.
>>>>
>>>> -W
>>>>
>>>> On Tue, Dec 29, 2009 at 6:23 PM, Adam Zell <zellster_at_gmail.com <mailto:
>>>> zellster_at_gmail.com>> wrote:
>>>>
>>>> Hello,
>>>>
>>>> I have two basic schema files. The second schema file imports the
>>>> first, and uses the hash character in its target namespace.
>>>>
>>>> foo.xsd:
>>>>
>>>> <?xml version="1.0" encoding="UTF-8"?>
>>>> <xs:schema elementFormDefault="qualified"
>>>> attributeFormDefault="unqualified"
>>>> targetNamespace="http://www.foo.com/ns"
>>>> xmlns:xs="http://www.w3.org/2001/XMLSchema"
>>>> xmlns:foo="http://www.foo.com/ns">
>>>> <xs:element name="Foo">
>>>> <xs:complexType>
>>>> <xs:sequence>
>>>> <xs:element name="foo" type="xs:string"/>
>>>> </xs:sequence>
>>>> </xs:complexType>
>>>> </xs:element>
>>>> </xs:schema>
>>>>
>>>> bar.xsd:
>>>>
>>>> <?xml version="1.0" encoding="UTF-8"?>
>>>> <xs:schema elementFormDefault="qualified"
>>>> attributeFormDefault="unqualified"
>>>> targetNamespace="http://www.foo.com/ns#bar"
>>>> xmlns:xs="http://www.w3.org/2001/XMLSchema"
>>>> xmlns:bar="http://www.foo.com/ns#bar">
>>>> <xs:import namespace="http://www.foo.com/ns"
>>>> schemaLocation="foo.xsd"/>
>>>> <xs:element name="Bar">
>>>> <xs:complexType>
>>>> <xs:sequence>
>>>> <xs:element name="bar" type="xs:string"/>
>>>> </xs:sequence>
>>>> </xs:complexType>
>>>> </xs:element>
>>>> </xs:schema>
>>>>
>>>> xjc 2.1.12 reports the following:
>>>>
>>>> $ ./jaxb-ri-20090708/bin/xjc.bat -d build/classes -verbose *.xsd
>>>> parsing a schema...
>>>> compiling a schema...
>>>> [INFO] generating code
>>>> unknown location
>>>>
>>>> com\foo\ns\Foo.java
>>>> com\foo\ns\ObjectFactory.java
>>>> com\foo\ns\package-info.java
>>>> com\foo\ns_bar\Bar.java
>>>> com\foo\ns_bar\ObjectFactory.java
>>>> com\foo\ns_bar\package-info.java
>>>>
>>>> xjc 2.2 however reports:
>>>>
>>>> $ ./jaxb-ri-20091104/bin/xjc.bat -d build/classes -verbose *.xsd
>>>> parsing a schema...
>>>> compiling a schema...
>>>> [INFO] generating code
>>>> unknown location
>>>>
>>>> com\foo\ns\Bar.java
>>>> com\foo\ns\Foo.java
>>>> com\foo\ns\ObjectFactory.java
>>>> com\foo\ns\package-info.java
>>>>
>>>> Is the difference in xjc behavior due to the hash character in
>>>> bar's target namespace?
>>>>
>>>> Thanks!
>>>>
>>>> -- Adam
>>>> zellster_at_gmail.com <mailto:zellster_at_gmail.com>
>>>>
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe_at_jaxb.dev.java.net
>>> For additional commands, e-mail: users-help_at_jaxb.dev.java.net
>>>
>>>
>>
>
>
> --
> Adam
> zellster_at_gmail.com
>