But what meaning would a file with extension in a URI of a
targetNamespace have? Would a namespace like
"http://anything.com/myfault.html"; not be a mistake by the user? And if
so, shouldn't the user then correct the namespace if he does not like a
package like "com.anything.myfaulthtml"?
Backwards-compatibility cannot be abandoned, of course. The question is
how many users already have a namespace like the one above and arranged
with the existing transformation rule. A workaround could be to include
the version number before the last slash, e.g.
"http://foo.bar/v01.01.00/myconcern"; ... or just use version numbers
with hyphens instead of dots.
However, I just wanted to make sure whether this was a bug and could be
fixed in a future version or not.
Thanks,
Johannes
Radu Preotiuc-Pietro wrote:
Yeah, this is actually true, but not bug.
The reason for it is that the rule for transforming URIs into package
names says: if the part after the last slash looks like a file with
extension, then strip the extension, where file with extension is
interpreted as "anything + '.' + 3 chars" or "anything + '.' + 2 chars"
or "anything + '.html'". Your v01.01.00 string triggers this rule.
Now I can see what you're saying, but I am reluctant to changing this
since I don't know exactly what the new rule would be and also for
backwards-compatibility reasons.
Radu
-----Original Message-----
From: Johannes Echterhoff [mailto:[EMAIL PROTECTED]
Sent: Tuesday, December 06, 2005 4:51 AM
To: [email protected]
Subject: problem concerning version number in targetNamespace
Hello.
For handling different schema versions it could be nice to
include the
version number in the targetNamespace of a schema (see
http://www.devx.com/xml/Article/22553 to get an overview of
what I mean).
So I tested this a little bit. The following schema is my
test schema (I
compile it using the xmlbeans ant task):
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema";
xmlns="http://foo.bar/v01-01-00";
targetNamespace="http://foo.bar/v01-01-00";
elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:element name="Root">
<xs:complexType>
<xs:sequence>
<xs:element name="foobar" type="xs:string"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
The resulting package for the generated classes is: bar.foo.v010100 -
alright.
But if I change the targetNamespace to v01.01.00 the
resulting package
is bar.foo.v0101! If I use v00.01.10 as version number the resulting
package is bar.foo.v0001 whereas if i use v00-01-10 it's
bar.foo.v000110
Seems to me that if I use a version number like vx.y.z with
x, y and z
being any number of digits the third part of the version
number - z - is
completely ignored when using dots to separate version fragments. I
compiled with v0123456.1.01 and the result was
bar.foo.v01234561 (using
hyphens the result is bar.foo.v0123456110).
Is this a bug? It would be nice to be able to compile schemas that
include the schema version in their targetNamespace correctly even if
the version number uses dots. What do you think of this?
Regards,
Johannes
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
