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]
