Radu, Thanks for the mail. I see your point and why it works as it does.
I guess one common problem that many of us using Xmlbeans face is the fact that we do not control the Xml Schemas we have to work with. Therefore we often have to work with schemas that are not 100% correct. This is a case in point, I have no control over the Schema and yes I can modify it to fix it up but I am loathe to do so as we then have a version out of sync with the other party. However, I have to say that it is frustrating that Xmlbeans does not, by default, use the prefix defined for a namespace from the Schema. It means that whenever an XML document is instantiated from the beans invariably the prefix is different to that in the schema. This means that code has to be written define the save mappings which makes the java code tightly coupled to a namespace change. With regards to 'Using the same prefix as the one present in the Schema is interesting as an idea' herein lies another gotcha. If I use XQuery or XSL on the output of Xmlbeans and the prefix output is different to the schema. A developer can use Stylus Studio or XMLSPy to create XML or Xquery on the schema. If the input to the XSL or Xquery comes from Xmlbeasn then the code in XQuery and XSL has to be modified to the Xmlbeans prefix and not the schema prefix. This just proliferates a problem and with multiple developers on a project refering to the schema it does get a little confusing if differing code files use different prefixes for the same namespace. Rather than changing setSaveSuggestedPrefixes() can you not add setSuggestedPrefixes() as now taking a Map or a setQNamePrefix() to change a single new instance of an XmlObject? Many Thanks 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]
