Don, I can certainly understand your frustration, having to deal with this problem, in no way did I mean to minimize the issue you're having. Particularly since you have been such an important contributor to the project by means of feedback and support on the mailing list. But on the other hand, you too have to understand that when XmlBeans derails from the spec it's a more urgent issue for us than when a client doesn't behave properly, because more users are likely to be affected by it, whereas it's impossible to predict all cases in which we have to provide abilities the spec doesn't call for. Also, this particular case is difficult enough to provide a supporting feature for, that I am unable to give you a patch that will solve your problem.
What I reccomend (unless you feel you have the resources to implement said feature yourself, in which case I would definitely be happy to help) is create a generic method that will transform the object produced by .changeType() in the following way: - look for an 'xmlns' declaration pertaining to the namespace of the type (using XmlCursor) - remove said declaration (using XmlCursor again) - look for an "xsi:type" attribute - replace the prefix of the declaration from step 1 with the prefix of your choice I know this is more code than you would ideally like to write but: - it would be relatively easy to implement (certainly compared to the 2 weeks you already spent on this) - it would be robust - depending on how your code is structured, it would be easy for you to change the code so it uses this method and then replace it when a more elegant solution becomes available - it would be generic so you can maybe post it on the list if you want - you would have complete control over what's going on. Hope this helps, Radu -----Original Message----- From: Don Stewart [mailto:[EMAIL PROTECTED] Sent: Friday, July 08, 2005 6:56 AM To: [email protected] Subject: RE: Namespace question type derivation causing issue - URGENT ! LOL um yes of course, that is one way to do it. Don -----Original Message----- From: maarten [mailto:[EMAIL PROTECTED] Sent: 08 July 2005 14:28 To: [email protected] Subject: Re: Namespace question type derivation causing issue - URGENT ! Maybe a very silly suggestion, but couldn't you save the output generated by xmlbeans into a String and use s.replaceAll ("xx","yy") until the output is acceptable. I do the same thing, for example when I want certain attributes to be on a new line. Maarten Don Stewart wrote: >Radu, Folks, > >I am still struggling with Xmlbeans and namespaces, that is since >before the 23rd June. I know the XML Schema I have may not be 100% >correct, but it's not under my control as it is the clients. > >I simply have to be able to control the prefixes used in code >generation. The autocreation of the namespace prefix by Xmlbeans is of >no use as the server side will not accept the XML documents created >with the XMLBeans prefix. > >Is there no way (say in the xsdconfig) file that I can force a prefix >onto the QNames generated. The output from scomp shows:- > >QName : URI "urn:xxxx/tML/Assurance.ServiceAction", localPart >ServiceInformationErrorInfo, prefix > >where the prefix is blank. The prefix defined for this urn in the >schema is dt: whereas Xmlbeans creates ass: > >I have to supply dt: there is no option for me. As the schemas use >derived types etc. there are all sorts of issues. I have spent hours >and hours on this and still cannot get suitable output to this problem. > >So to follow up on your comment Radu, 'Using the same prefix as the one >present in the Schema is interesting as an idea'. In my case here it's >not an idea the server enforces this and rejects XML that does not. >This may not be as per spec and a host of other reasons why it should, >but this is a real world project with all the issues that that presents. > >Hoping for a miracle.... > >Regards > >Don > >-----Original Message----- >From: Radu Preotiuc-Pietro [mailto:[EMAIL PROTECTED] >Sent: 23 June 2005 22:01 >To: [email protected] >Subject: RE: Namespace question type derivation causing issue > >This is indeed caused by your use of type derivation, more specifically >by the way QName values work. >The problem that XmlBeans faces internally is that when you use a type >that's a derivation of the declared type (in your case DetailedFoo in >place of Foo), it needs to use an xsi:type attribute whose value is a >QName. >Because of the way QName values work, we need to declare a prefix in >order to insert one as text, *at the time you insert the value*. On the >other hand, the saveXXX() options work at the time you save the >document and basically the rule is that saving a document will not >alter the infoset. It is the interaction of these rules that makes so >that you can't use setSaveSuggestedPrefixes() to control the prefix >used for the value of xsi:type. > >The solution to this would be to change setSaveSuggestedPrefixes() to >setSuggestedPrefixes() in other words to add a "newInstance" option >instead of a "save" option to control prefixes from the beggining. >Using the same prefix as the one present in the Schema is interesting >as an idea, but it would accomodate less use-cases and would require us >to persist the prefix value in the .xsd binaries, which we currently >don't do. > >Radu > >-----Original Message----- >From: Don Stewart [mailto:[EMAIL PROTECTED] >Sent: Tue 6/21/2005 4:06 AM >To: [email protected] >Cc: >Subject: Namespace question type derivation causing issue >Okay I've progressed this (I think) > >Where this is the output:- > > <dt:Parent> > > <dt:A/> > > <ass:Foo xmlns:ass="urn:bla/blabla/Assurance" >xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; >xsi:type="ass:DetailedFoo"> > > </ass:Foo> > > <dt:B/> > > </dt:Parent> > >As I mentioned Foo is actually a DetailedFoo a derived type of Foo. I >created DetailedFoo and do an xmlText on the Document and its fine. >I add the DetailedFoo to the dt:Parent using Parent.setFoo() method >which appears on the cast to revert the namespace to <ass:Foo>. The >DetailedFoo type is defined in a separate schema which includes the >schema defining Foo. Both have the same namespace definition in their >respective schemas. > >Regards > >Don > >-----Original Message----- >From: Don Stewart [mailto:[EMAIL PROTECTED] >Sent: 21 June 2005 10:10 >To: [email protected] >Subject: RE: Namespace question > >A quickie, > >I am presuming that the reason that the tag has had its namespace >redefined is that's it's from an included schema. > >Can someone confirm this is the case. > >Don > >-----Original Message----- >From: Don Stewart [mailto:[EMAIL PROTECTED] >Sent: 21 June 2005 09:47 >To: [email protected] >Subject: RE: Namespace question > >Jacob, > >Thanks for the response. > >I also tried that in fact I've tried all the namespace functions in >different combinations, aprat from the correct one :o) > >Don > >-----Original Message----- >From: Jacob Danner [mailto:[EMAIL PROTECTED] >Sent: 20 June 2005 18:03 >To: [email protected] >Subject: RE: Namespace question > >Hey Don, >I can't tell you why this happens, but I can suggest something to work >around it. >On your XmlOptions try setting >setAggressiveNamespace() >and setSaveNamespacesFirst ><file:///H:/svn/xmlbeans/trunk/build/docs/reference/org/apache/xmlbeans >/ XmlOptions.html#setSaveNamespacesFirst%28%29> () Good Luck, -Jacobd > > -----Original Message----- > From: Don Stewart [mailto:[EMAIL PROTECTED] > Sent: Mon 6/20/2005 9:26 AM > To: [email protected] > Cc: > Subject: Namespace question > > > Hi, > > I'm getting an issue with namespaces that I cannot figure out. >My schema (read customers) defines a namespace:- > > xmlns:dt="urn:bla/blabla/Assurance" > > > > Without any XmlOptions I get :- > > <ass:Parent> > > <ass:A/> > > <ass:Foo xmlns:ass="urn:bla/blabla/Assurance" >xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; >xsi:type="ass:DetailedBla"> > > </ass:Bla> > > <ass:B/> > > </ass:Parent> > > > > When I generate I set the XmlOptions with :- > > XmlOptions xmlOptions = new XmlOptions(); > xmlOptions.setSavePrettyPrintIndent(4); > xmlOptions.setSavePrettyPrintOffset(4); > xmlOptions.setSavePrettyPrint(); > xmlOptions.setLoadLineNumbers(); > Map namespaceMap = new HashMap(); > namespaceMap.put("dt", "urn:bla/blabla/Assurance"); > xmlOptions.setLoadSubstituteNamespaces(namespaceMap); > xmlOptions.setSaveImplicitNamespaces(namespaceMap); > > > > The prefix changes to <dt:Foo> > > All except one inner block that starts as <ass: where the namespace is >redefined to be the same. > > Now what differs in the generation is that Foo is a derived type so >its actually a DetailedFoo which I create using the >DetailedFoo.Factory.newInstance(xmlOptions) method passing in the same >XmlOptions as above i.e. with the namespace mapping that worked for all >the other tags. I then use a Parent.setFoo() method to add it to the >Parent XmlObject. This is because Parent has only a setFoo() and not a >Parent.setDetailedFoo(). > > Can anyone tell me why I end up with :- > > <dt:Parent> > > <dt:A/> > > <ass:Foo xmlns:ass="urn:bla/blabla/Assurance" >xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; >xsi:type="ass:DetailedFoo"> > > </ass:Foo> > > <dt:B/> > > </dt:Parent> > > > > I realise that the redefinition of the element is causing it to be >redined but why is this sub-element not subject to remapping the same >as the other level. Anyone shed some light on this for me ?? > > > > Many Thanks > > > > Don > > >--------------------------------------------------------------------- >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] --------------------------------------------------------------------- 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]
