Hi Peter and thanks for the explanation. It's been awhile; I've been on vacation for a week.
Anyway, I tried what you said about the XPath expressions and it looks like you're correct. I'm using the Java core XPath libraries and the prefix I set in an instance of NamespaceContext is what dictates how the expression is evaluated. So two documents: <xxx:root xmlns:xxx="a"/> and <yyy:root xmlns:yyy="a"/> can both be successfully queried with "//xxx:root" as long as the NamespaceContext object maps the "xxx" prefix to the "a" namespace. In short, the NamespaceContext for the XPath statement takes precedence and the prefixes in the document are not significant. Our project produces both a file specification and an application that helps create specification compliant documents. However, someone could create their own document outside of the application and use whatever prefix they wish. So we have to accept different prefixes; a scenario I did not consider previously. Our application also exposes APIs and allows users to create plugins, so they would be able to access the XMLBeans-generated classes directly. We'd have mismatching prefixes if we used XmlOptions for output that a plugin developer did not. Your explanation has helped me understand these issues and when/why prefixes are/aren't significant and I've been able to write unit tests to demonstrate the understood behavior. FWIW, the reason I'm using the Java core libraries for XPath is because I can't get XMLBeans to do it correctly inside the NetBeans platform. XMLBeans can't find supporting libraries across module dependencies due to class path issues; each module has its own class path and XMLBeans only checks it's own. Michael On Fri, Aug 8, 2014 at 6:58 AM, Peter Keller <pkel...@globalphasing.com> wrote: > Hi Michael, > > OK - now this is getting to the heart of the question... > > On Thu, 2014-08-07 at 16:02 -0400, Michael Bishop wrote: > > Hi Peter, > > > > You're right, I came across that table recently since I've been > > working at this problem most of the day. Let me share one more thing > > I've discovered. It appears that XMLBeans has always been ignoring my > > namespace prefixes. In URL form, it will use the last "token" and in > > URN form, it will use the first: > > > > > > xmlns:aaa="http://test.example.com/TOKEN"; > > xmlns:bbb="TOKEN:xxx:yyy:zzz" > > I use tag (i.e. RFC4151) URI's, and XMLBeans takes the first token, like > with URN URI's. Obviously, since all such URI's begin with "tag:", it > can only do this for the first one that it hits. I am lucky, in that I > don't care :-) > > > In other words, the declared (xmlns:...) prefixes above are never > > honored. In both cases, TOKEN will end up being the prefix. I thought > > this had worked before because my old namespace was: > > > > > > xmlns:aaa="http://test.example.com/aaa"; > > > > > > Changing the trailing "aaa" in the URL will change the prefix in the > > generated document. > > > > > > So why do I need the same prefix? > > > > > > Our application is transitioning from version X to version X.1. > > Our customer has requested a namespace change to URN form. > > We have extensive documentation and screen shots that show the old > > prefix. > > Yes, I can see that this is a nuisance. > > > We also have XPath statements scattered throughout our application > > that reference the old prefix. > > Looking at the XPath/selectPath example here: > < > http://xmlbeans.apache.org/docs/2.0.0/guide/conSelectingXMLwithXQueryPathXPath.html> > I don't think that the prefix used in queryExpression needs to be the same > as in the document, i.e. if you changed the query to this: > > > String queryExpression = > > "declare namespace xq1=' > http://xmlbeans.apache.org/samples/xquery/employees';" + > > "$this/xq1:employees/xq1:employee/xq1:phone[contains(., '(206)')]"; > > the query should still work, even though the document has "xq" as the > prefix. The scope of the prefix declaration here should the query only, > and it should get mapped to the namespace itself when querying the > document. I can't remember if I have ever tried this with XMLBeans or > not, but it works with other XML utilities that I have used. Worth a > try, maybe? > > > It was believed that it would be far less of a hassle to correct the > > prefix than it would to correct all our documentation and XPath > > statements. > > Hm, the problem is that AFAIK nothing in the XSD standard mandates the > stability of the prefix: it is the namespace name itself that matters. > From the XSD point of view, any application that treats the prefix as > data has fragility built-in. > > > In our application, when a user creates a new instance of the > > document, it uses Factory.newInstance() which results in a document > > with the wrong namespace. > > I assume that you mean "wrong prefix" here? The namespace itself should > be fine. > > > Like a lot of other applications (Word, Excel, etc.), our files reside > > "in memory" until they are saved. So a new document would carry the > > wrong prefix until it was saved. > > Ah, here is the fallacy, I think. When you call Factory.newInstance(), > the instantiated element doesn't carry a prefix with it as such. As far > as XMLBeans is concerned, the element's QName is > "{TOKEN:xxx:yyy:zzz}test", i.e. uses the full namespace string. The > prefix only makes its appearance when you call "save" or "xmlText", and > then you can always suggest the prefix that should be used. If you > added a suitable XmlOptions argument to every call to xmlText in your > application, would that achieve what you are after? Or are you using > XmlCursor or some other lower-level trickery to get at the xmlns > declarations? > > > Even after it was saved, it would have to be reloaded by the > > application to have the correct prefix "in-memory." > > Yes, if replacing every xmlText() call with xmlText(xmlOptions) isn't > feasible, I can't see any way other than save/parse to achieve this. > Using streams or Reader/Writer may be more efficient than writing to a > file and reading it back. > > > Our application also has the ability to digitally sign documents. > > Signing one prefix, then saving another causes the signature to break. > > I hadn't thought of this scenario, but yes, this is an example of using > the prefix as data. > > > So the options are starting to look like this: > > > > 1. Figure out why XMLBeans doesn't honor my xmlns:... declarations. > > > > 2. Change the namespace URN to start with the desired prefix. > > Obviously, this is a workaround. > > > > 3. Use the new prefix and change everything else to suit. > > > > > > So I guess my first question (in this email at least) is does XMLBeans > > ever try to honor xmlns prefix declarations? > > As I said, in my understanding there is nothing to honour before > save/xmlText is called. Prefixes only materialise when the element is > serialised. Otherwise, they are only known about externally such as in > declarations in XPath/XQuery expressions. > > > If so, what's wrong with the schema I posted that causes this not to > > happen? > > Nothing: AFAICS this is XMLBeans intended behaviour. > > > Can anyone get the schema I previously posted to use the aaa prefix as > > declared? > > I doubt that that would be possible without patching XMLBeans (although > I would be quite happy to be proved wrong here). I appreciate the > digital signing issue, but as far as I can see the only way of robustly > specifying the prefix is at the save/xmlText level. > > Having said that, there are corners of XMLBeans that I have never > explored, so maybe there is another approach that someone else may be > able to suggest. > > I hope that these thoughts are of some use to you. > > Regards, > Peter. > > > > > > > Michael > > > > > > > > On Thu, Aug 7, 2014 at 3:32 PM, Peter Keller > > <pkel...@globalphasing.com> wrote: > > Hi Michael, > > > > There is a table in the Javadocs that states which options are > > used by > > which methods: see > > < > http://xmlbeans.apache.org/docs/2.6.0/reference/org/apache/xmlbeans/XmlOptions.html>. > You have to make the prefix suggestion in the options to a save or xmlText > method: they won't have any effect in a newInstance method. What you have > observed here is expected and documented. > > > > Maybe I'm missing something, but I can't think of any scenario > > where > > this is going to cause any problems. If you really need the > > prefix to be > > a particular string before you get to the stage of writing or > > saving the > > XML document, perhaps you could explain why? Then we might be > > able to > > think of other ways to solve the issue. > > > > Regards, > > Peter. > > > > On Thu, 2014-08-07 at 13:53 -0400, Michael Bishop wrote: > > > OK, here is a test schema: > > > > > > <?xml version="1.0" encoding="UTF-8" ?> > > > <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"; > > > xmlns:aaa="bbb:ccc:ddd:eee:fff:aaa" > > > targetNamespace="bbb:ccc:ddd:eee:fff:aaa" > > > elementFormDefault="qualified"> > > > > > > <xs:element name="test" type="aaa:testType"/> > > > > > > <xs:complexType name="testType"> > > > <xs:sequence> > > > <xs:element name="name" type="xs:string" > > minOccurs="1" > > > maxOccurs="1"/> > > > <xs:element name="uuid" type="xs:string" > > minOccurs="1" > > > maxOccurs="1"/> > > > <xs:element name="version" type="xs:string" > > minOccurs="1" > > > maxOccurs="1"/> > > > <xs:element name="created" type="xs:string" > > minOccurs="1" > > > maxOccurs="1"/> > > > <xs:element name="createdBy" type="xs:string" > > > minOccurs="1" maxOccurs="1"/> > > > <xs:element name="modified" type="xs:string" > > minOccurs="1" > > > maxOccurs="1"/> > > > <xs:element name="modifiedBy" type="xs:string" > > > minOccurs="1" maxOccurs="1"/> > > > <xs:element name="description" type="xs:string" > > > minOccurs="0" maxOccurs="1"/> > > > </xs:sequence> > > > <xs:attribute name="version" type="xs:string" > > use="required"/> > > > </xs:complexType> > > > </xs:schema> > > > > > > > > > TestDocument doc = TestDocument.Factory.newInstance(); > > > doc.addNewTest(); > > > > > > // Wrong, default Factory output. > > > doc.xmlText(): <bbb:test > > xmlns:bbb="bbb:ccc:ddd:eee:fff:aaa"/> > > > > > > > > > // Correct output that I can't get from just the > > Factory.newInstance() > > > method. > > > doc.xmlText(options): <aaa:test > > xmlns:aaa="bbb:ccc:ddd:eee:fff:aaa"/> > > > > > > > > > Does anyone else get the same compilation results? Is there > > a reason > > > the new instances won't default to xmlns:aaa as declared? > > I'd be hard > > > pressed to believe that something in XMLBeans is causing > > this. It's > > > probably something I'm doing. Does the XSDConfig file have > > any > > > influence that I'm missing? > > > > > > > > > Michael Bishop > > > > > > > > > > > > On Thu, Aug 7, 2014 at 1:22 PM, Michael Bishop > > <bisho...@gmail.com> > > > wrote: > > > I've got to figure out how to debug it. Currently, > > it's in a > > > Maven project with the XMLBeans plugin running the > > schema > > > compilation. > > > > > > > > > The map works when I call save(options) or > > xmlText(options), > > > but not when the document is created > > > (Factory.newInstance(options)). > > > > > > > > > > > > // Option that sets the namespace map. > > > > > > XmlOptions options = ...; > > > > > > > > > MyDoc doc = MyDoc.Factory.newInstance(options); > > > > > > > > > System.out.println("Wrong prefix: " + > > doc.xmlText()); > > > > > > System.out.println("Right prefix: " + > > doc.xmlText(options)); > > > > > > > > > The schema is spread out across multiple files. I'm > > going to > > > try to create a small test case to see if I can't > > reproduce > > > this. > > > > > > > > > > > > On Mon, Aug 4, 2014 at 4:31 PM, Cezar Andrei > > > <cezar.and...@oracle.com> wrote: > > > Michael, > > > > > > That's odd, please check that your namespace > > URI is > > > exactly the same in both the schema and the > > map you're > > > setting. Also, make sure the prefix you want > > is not > > > already used in your document with a > > different URI. > > > > > > If it's still not working and you're not > > afraid of > > > debugging, you can trace the ensureMapping > > method in > > > Saver.java:757 . > > > > > > http://svn.apache.org/viewvc/xmlbeans/trunk/src/store/org/apache/xmlbeans/impl/store/Saver.java?view=markup > > > > > > Cezar > > > > > > > > > On 08/02/2014 02:04 PM, Michael Bishop > > wrote: > > > > > > OK, thanks for the information. > > Unfortunately, > > > this doesn't seem to fix the > > problem. I > > > thought I'd tried the steps outlined > > in the > > > linked blog before, but I did it > > again, just > > > in case. > > > > > > Here's the full schema definitions: > > > > > > Old: > > > <xs:schema > > > > > xmlns:xs="http://www.w3.org/2001/XMLSchema"; > > > > > > *xmlns:xxx="http://..."* > > > > > > > > targetNamespace="http://..."; > > > > > elementFormDefault="qualified"> > > > > > > New: > > > <xs:schema > > > > > xmlns:xs="http://www.w3.org/2001/XMLSchema"; > > > > > > *xmlns:xxx="yyy:aaa:bbb..."* > > > > > > targetNamespace="yyy:..." > > > > > elementFormDefault="qualified"> > > > > > > > > > As you can see, in both schemas, I'm > > declaring > > > a namespace of *xxx*, but it's only > > honored in > > > the old schema. The only thing > > that's changed > > > between schemas is the namespace. I > > had a > > > request from our customer to change > > it. > > > However, a call to: > > > > > > > > > > > MyGeneratedClass.Factory.newInstance() results > > > in a document that looks like this: > > > > > > <yyy:root > > xmlns:yyy="yyy:aaa:bbb..."/> > > > > > > Applying a namespace map to an > > XmlOptions > > > object doesn't seem to have any > > effect. I've > > > tried it with the call to > > > > > MyGeneratedClass.Factory.newInstance() and a > > > call to > > MyGeneratedInstance.xmlText(): > > > > > > XmlOptions options = new > > XmlOptions(); > > > Map<String, String> nsMap = new > > HashMap<>(); > > > nsMap.put("yyy:aaa:bbb", "xxx"); > > > > > options.setSaveSuggestedPrefixes(nsMap); > > > > > > // No change to output. > > > > > MyGeneratedClass.Factory.newInstance(options); > > > > > MyGeneratedInstance.xmlText(options); > > > > > > I guess I have two questions: > > > > > > > > > 1. Why is the prefix declaration in > > my schema > > > being ignored? *xmlns:xxx* has never > > changed. > > > It's only the value of the namespace > > that has > > > changed. > > > > > > 2. I find it odd that Map has no > > effect > > > either. Is there anything else I > > should be > > > looking into? I'm not sure if my > > schema is > > > somehow "wrong" or I have a setting > > in > > > XMLBeans misconfigured. It's > > becoming more > > > than just an annoying problem. XPath > > > statements are now broken since they > > employ > > > the *xxx* prefix. I'm not sure where > > to start > > > tracking down the issue. Both the > > guidance and > > > the docs seem straightforward to me, > > yet I > > > can't get it to work properly. > > > > > > > > > Any guidance is appreciated. I'm on > > XMLBeans > > > 2.5.0. If there's anything more I > > can provide, > > > I can do so. > > > > > > Michael Bishop > > > > > > > > > > > > On Fri, Aug 1, 2014 at 12:10 PM, > > Cezar Andrei > > > <cezar.and...@oracle.com > > > <mailto:cezar.and...@oracle.com>> > > wrote: > > > > > > If you don't provide a prefix, > > XmlBeans > > > will automatically pick a > > > prefix, and it tries to pick one > > that is > > > part of the URI. > > > > > > Cezar > > > > > > > > > > > > On 07/28/2014 01:27 PM, Michael > > Bishop > > > wrote: > > > > > > Hello all. I've recently > > changed the > > > namespace of my schema. > > > Now I'm getting the wrong > > prefix name > > > and I'm not sure why. > > > > > > Old namespace was: > > > > > > > > xmlns:*xxx*="http://ccc.bbb.aaa"; > > > > > > New namespace is: > > > > > > > > xmlns:*xxx*="*yyy*:aaa:bbb:ccc" > > > > > > With the old namespace, the > > prefix for > > > elements was xxx. Now > > > with the new namespace, the > > prefix fpr > > > elements is *yyy*. It > > > seems switching from URL > > form to URI > > > form has caused the > > > processor to start using the > > first > > > part of the URI as the > > > prefix? This happens when I > > call the > > > static > > > Factory.newInstance() on > > generated > > > classes. Older documents > > > with the correct prefix > > still parse > > > properly. > > > > > > It's not a big deal since > > the > > > namespace is intact and things > > > work as they should, but I > > can't > > > figure out why this is > > > happening. I don't declare > > xmlns:*yyy* > > > anywhere in the schema > > > or xsdconfig files. > > > > > > Michael Bishop > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: > > > user-unsubscr...@xmlbeans.apache.org > > > > > > > > > > > <mailto:user-unsubscr...@xmlbeans.apache.org> > > > > > > For additional commands, e-mail: > > > user-h...@xmlbeans.apache.org > > > > > > > > <mailto:user-h...@xmlbeans.apache.org> > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: > > > user-unsubscr...@xmlbeans.apache.org > > > For additional commands, e-mail: > > > user-h...@xmlbeans.apache.org > > > > > > > > > > > > > > > > > > > > > > > > -- > > Peter Keller Tel.: +44 > > (0)1223 353033 > > Global Phasing Ltd., Fax.: +44 > > (0)1223 366889 > > Sheraton House, > > Castle Park, > > Cambridge CB3 0AX > > United Kingdom > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: user-unsubscr...@xmlbeans.apache.org > > For additional commands, e-mail: user-h...@xmlbeans.apache.org > > > > > > > > > > -- > Peter Keller Tel.: +44 (0)1223 353033 > Global Phasing Ltd., Fax.: +44 (0)1223 366889 > Sheraton House, > Castle Park, > Cambridge CB3 0AX > United Kingdom > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: user-unsubscr...@xmlbeans.apache.org > For additional commands, e-mail: user-h...@xmlbeans.apache.org > >
