Extra slash in XSD location prevents customization

[glassfishrobot]

When XSD import URL contain extra slashes (like ".../xsd/types//types.xsd"), the
referring XSD is impossible to customize: the schema location is either silently
accepted (but no customization is performed) or it is rejected, e.g. when trying
to specify schemaLocation="xsd/types//types.xsd", the following error is triggered:

[ERROR] "file:/C:/test/xsd/types//types.xsd" is not a part of this compilation.
Is this a mistake for "file:/C:/test/xsd/types/types.xsd"?
line 11 of file:/C:/test/jaxb-binding.xml

Expected: URLs are compared correctly.

For the attached test case the following is generated:

parsing a schema...
compiling a schema...
net\myexample\AnyTypeArray.java
net\myexample\ObjectFactory.java
net\myexample\package-info.java
examples\jaxb\ExecuteSPARQLRequest.java
examples\jaxb\ExecuteSPARQLResponse.java
examples\jaxb\ObjectFactory.java
examples\jaxb\RDFStorageServiceException.java
examples\jaxb\package-info.java

Expected: "net.myexample" package is replaced by "examples.jaxb" as customized.

I have used jaxb-ri-20100511 (v2.1.13).

Environment

Operating System: All
Platform: All

Affected Versions

[2.1.13]

[glassfishrobot]

Reported by dma_k@java.net

[glassfishrobot]

Was assigned to snajper

[glassfishrobot]

dma_k@java.net said:
Created an attachment (id=364)
Test case demonstrating the problem

[glassfishrobot]

File: test.zip
Attached By: dma_k@java.net

[glassfishrobot]

gmazza said:
I'm not sure, from reading section 3.10 here 1 or 3.3 here
("Path")[2], whether the double-slash as a directory separator is acceptable in
a URI. Linux ignores it as directory path (if you cd aaa//bbb), but is that OK
in a URI?

Glen

[1] http://tools.ietf.org/html/rfc1738#section-3.10
[2] http://tools.ietf.org/html/rfc3986#section-3.3

[glassfishrobot]

gmazza said:
Let me rephrase that, from reading the relevant sections of those two RFCs, it
appears that the double-slash as a directory separator is not acceptable in a URI.

[glassfishrobot]

laune said:
The "path" part of an URI is defined as
*( "/" segment )
where
segment = *pchar
i.e., a sequence of zero or more characters (except some).

Thus, "/a//b" is a legal path; it contains three segments.

The fact that some OS interpret an URI containing "a//b" the same way as one
containing "a/b" is, as far as I could see, not addressed by RFC 3986.

[glassfishrobot]

gmazza said:
Hmmmm....I would think the definition of the "path" portion of a file URI
(Section 3.10 of RFC1738, as I gave in [1]) would take precedence over the
generic definition of the path portion of a URI (Section 3.3 of RFC 3986).
I.e., the acceptable values of a path are dependent on the scheme being
used--not all paths are kosher for all schemes. That said, zero-length
directory names are not explicitly precluded in 1738.

[glassfishrobot]

dma_k@java.net said:
If URL is invalid, I suppose java.net.URL should throw an exception. If it is
not the case, the handling should be correct.
I have created the file-testcase based on real example: parsing of WSDL, that
refers XSD by http://host.com/xsd//root.xsd. The same problem occurs in this
case as well. I agree that URL needs a cleanup, but usually nobody cares.

[glassfishrobot]

laune said:
XML Schema and have schemaLocation = anyURI. java.net.URI
methods equals( Object o) and compareTo( URI u ) both indicate not equal for two
URIs just differing w.r.t. a path segment delimiter "/" vs. "//". Applying
normalize() to an URI does not change "//" to "/".

I don't think that any system-independent processing of an anyURI value should
treat these two values as equal. There might be a system where '' (i.e., a
string with length 0) is a valid name component. Consider, for instance, that '
' (a single space) or " " (a string of spaces) are valid in an URI (and as
UNIX file or directory names).

Also, you can use, for instance:
"http://acme.com/sales/%2Ftalk.html"
which is (in Java) not equal to
"http://acme.com/sales//talk.html"
even though
new URI( "http://acme.com/sales/%2Ftalk.html" ).getPath()
returns
"/sales//talk.html"
(whereas
new URI( "http://acme.com/sales/%2Ftalk.html" ).getRawPath()
does return
"/sales/%2Ftalk.html"
).

I think that this issue should be closed as "INVALID".

[glassfishrobot]

gmazza said:
Laune, just to clarify: On the one hand, you're saying JAXB should accept and
process "file:/C:/test/xsd/types//types.xsd" and
"file:/C:/test/xsd/types/types.xsd" as schemaLocation values differently.
(Quote: "I don't think that any system-independent processing of an anyURI value
should treat these two values as equal.") OK, fine, that would seem to be in
agreement with dma_k's view that JAXB should be able to work with both those
valid two strings as a schemaLocation value and treat them differently, the
purpose of this bug report.

But at the end you do a 180 and say "I think that this issue should be closed as
'INVALID'." I would think you would only want this to be invalid if you felt
that "file:/C:/test/xsd/types//types.xsd" should not be allowed as a URI value
to begin with, right?

[glassfishrobot]

laune said:
(Generally, such things are better discussed on the JAXB user's list.)

The issue was raised because a part of some URI's path "a//b" isn't treated as
equal to another URI's "a/b" in the same position.

To summarize my remarks from yesterday and today:

• The duplicated slash is according to the syntax in RFC 3986.
• There's no indication anywhere that these two forms must (or even should) be
  treated as equal.

@gmazza: I don't think that these two statements are in contradiction with each
other.

[glassfishrobot]

gmazza said:
Laune, I think you misunderstood dma_k's original complaint:

"when trying to specify schemaLocation="xsd/types//types.xsd", the following
error is triggered:

[ERROR] "file:/C:/test/xsd/types//types.xsd" is not a part of this compilation.
Is this a mistake for "file:/C:/test/xsd/types/types.xsd"?
line 11 of file:/C:/test/jaxb-binding.xml"

He's not saying that schemaLocation="xsd/types//types.xsd" should be treated the
same as schemaLocation="xsd/types/types.xsd"; if I understand him correctly what
he is saying is that XJC should be able to work with
schemaLocation="xsd/types//types.xsd" without complaint (which it isn't doing
right now) and refer to something with a URL of "xsd/types//types.xsd", which
seems to be in agreement with your position.

[glassfishrobot]

dma_k@java.net said:
@gmazza: Than you for your comments & explanations: you are absolutely right.

I don't mind what to configure in customization file, but the main goal should
be achieved: the way to apply given customizations. Somehow internally JAXB
cleans up the URL (as it produces "file:/C:/test/xsd/types/types.xsd" without a
slash), so it should use either "cleaned-up" or "untouched" URLs for comparison.

[glassfishrobot]

laune said:
Yes, indeed, and sorry for my previous obfuscations. To clarify the problem
statement, here's a table with all possible combinations:

Using schemaLocation="..." in:

Schema Binding

a//b a//b - [ERROR]
a/b a//b - [ERROR]
a//b a/b - binding fails silently for imported XML Schema
a/b a/b - OK

[ERROR] "file:/x/xsd/types//types.xsd" is not a part of this compilation. Is
this a mistake for "file:/x/xsd/types/types.xsd"?
line 15 of file:/x/jaxb-binding.xml
Failed to parse a schema.

One would think that either all 4 cases should succeed; or the first and the
last; or only the last one - but then #3 should produce an error, too (or at
least a warning).

Note that there's a couple of TODOs in the comments in one of the
possibly pertaining classes, e.g., below com/sun/tools/xjc:
./reader/internalizer/Internalizer.java: // TODO: use the URI class
./reader/internalizer/Internalizer.java: // TODO: honor xml:base
but I haven't been able to follow all the path/systemID conversions going on there.