Thanks for the information. Now I see that there are good reasons for
using such a namespace. Sorry for saying that this could be a mistake. I
just have not seen a namespace like that before and did not know what
benefit it could have.
Johannes
Radu Preotiuc-Pietro wrote:
People do have namespaces like "http://www.name.com/foo/schema.xsd";, so
that the namespace URI is also the download page for the document. It's
hard to make the argument that having something like that is a mistake;
and the generated package name for that is currently
"com.name.foo.schema". In my experience, I have never seen an URI ending
in .-separated numbers though (well, until now that is)
So in this case, the answer is: no, it's not a bug, it was a design
choice, the design could be changed in the future, but I would recommend
against doing so, for backwards-compatibility reasons.
Radu
-----Original Message-----
From: Johannes Echterhoff [mailto:[EMAIL PROTECTED]
Sent: Thursday, December 08, 2005 1:08 AM
To: [email protected]
Subject: Re: problem concerning version number in targetNamespace
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]
---------------------------------------------------------------------
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]
