It may be worth mentioning that you can use xsdconfig files to override the default mapping from a given namespace to a package name and pick anything you want. (Although the package name you pick obviously has to be a valid Java package name - so you can't have just numbers).
You will then have to keep the xsdconfig file with the schema of course but that may help you. A link was recently posted in another mail on this list to an article explaining how all this works - http://dev2dev.bea.com/pub/a/2004/11/Configuring_XMLBeans.html. Cheers, Lawrence > -----Original Message----- > From: Johannes Echterhoff [mailto:[EMAIL PROTECTED] > Sent: Friday, December 09, 2005 1:00 AM > To: [email protected] > Subject: Re: problem concerning version number in targetNamespace > > 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
