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]
