Hi Vasil, SDO could try to deduce the element to use, but in the general case it may not be a trivial thing to figure out. For example, what if you had two elements:
<xsd:element name="priceQuote1" type="pri:PriceQuote"/> <xsd:element name="priceQuote2" type="pri:PriceQuote"/> Which one should it use? Also, when deducing the namespace, there may be priceQuote elements in more than one schema, or even if there is only one, it might be in a different schema (namespace) then the object type. Another possibility is that there may be an element, but the type is not PriceQuote, but instead some base class (e.g., BaseQuote). SDO has taken the approach of never guessing on this. If we wanted to add support to deduce the property, we would need to document very clearly what it deduces and when it doesn't. The most I personally think might be worthwhile is to deduce the element if the name is given and it is in the same schema as the type. Frank. Vasil Vasilev <[EMAIL PROTECTED]> wrote on 09/06/2007 04:38:00 PM: > Hi, > > I tried to give a namespace in SDO object serialization. The reult > was satisfactory: > > with null namespace parameter: > <priceQuote xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xmlns:pri=" > http://www.example.org/price"; xsi:type="pri:PriceQuote"> > <customerName>Acme Inc</customerName> > ............... > > with non-null namespace parameter: > <pri:priceQuote xmlns:pri="http://www.example.org/price";> > <customerName>Acme Inc</customerName> > ............... > > However, I think that the serializer should be able to deduce the > right namespace (it is available in the factory) if the argument is null. > > One more thing: the serializer should be able to deduce the correct > root element name if null is given as parameter to the > serialization. It can deduce it from the schema, where I have > written the root element: > > <xsd:element name="priceQuote" type="pri:PriceQuote"/> > > Then during generation of the SDO types this element name can be > preserved (for example in the factory), the same way as the > namespace and the prefix are preserved and later it can be used in > the serialization. > > What do you think about this? > > Bye, Vasil > > >-------- Оригинално писмо -------- > >От: "Raymond Feng" <[EMAIL PROTECTED]> > >Относно: Re: Current XQuery implementation issues > >До: <[email protected]> > >Изпратено на: Вторник, 2007, Август 28 01:02:53 EEST > >---------------------------------- > > > >Hi, > > > >Please see my comments inline. > > > >Thanks, > >Raymond > > > >----- Original Message ----- > >From: "Vasil Vasilev" <[EMAIL PROTECTED]> > >To: <[email protected]> > >Sent: Monday, August 27, 2007 1:17 PM > >Subject: Re: Current XQuery implementation issues > > > > > >> Hi all, > >> > >> First some update of the Saxon related issues: You can see TUSCANY-1536 > >> for information what I have changed. Could someone apply the changes in > >> the repository? > > > >I'll apply the patch. Thank you for the contribution. > > > >> > >> When I applied the changes I found the following problems: > >> > >> 1. When serializing DataObject to stream using the following code: > >> XMLHelper.save(DataObject, null, rootElementName, OutputStream); > >> No prefices are attached to the serialized xml elements. This issomething > >> that is introduced recently, because previously the behavior is was > >> different - each element was prefixed with the right prefix. > > > >Did you try to use a non-null namespace? > > > >> > >> 2. If you open the xqueryquotewsclient.composite file you will see that I > >> set xml properties to the QuoteJoinPropertiesComponent. If you note you > >> will see that I have described each element and each attribute of the xml > >> with a prefix. For example: > >> > >> <pri:priceQuote xmlns:pri="http://www.example.org/price";> > >> <pri:customerName>Acme Inc</pri:customerName> > >> <pri:shipAddress pri:street="12 Springs Rd" > >> pri:city="Morris Plains" pri:state="nj" pri:zip="07960" /> > >> .... > >> > > > >This style corresponds to the XSD attributeFormDefault="qualified". > > > >> However if I omit the prefices of the attributes: > >> > >> <pri:priceQuote xmlns:pri="http://www.example.org/price";> > >> <pri:customerName>Acme Inc</pri:customerName> > >> <pri:shipAddress street="12 Springs Rd" city="Morris > >> Plains" state="nj" zip="07960" /> > >> > > > >This style corresponds to the XSD attributeFormDefault="unqualified" which > >is the default. > > > >> An exception is thrown during initialiation of the SCA domain: > >> > >> org.osoa.sca.ServiceRuntimeException: java.lang.NullPointerException > >> at > >> org.apache.tuscany.sca.host.embedded.SCADomain. > createNewInstance(SCADomain.java:264) > >> at > >> org.apache.tuscany.sca.host.embedded.SCADomain. > newInstance(SCADomain.java:69) > >> at > >> xquery.quote.XQueryQuoteClientTestCase. > startClient(XQueryQuoteClientTestCase.java:69) > >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > >> at > >> sun.reflect.NativeMethodAccessorImpl. > invoke(NativeMethodAccessorImpl.java:39) > >> at > >> sun.reflect.DelegatingMethodAccessorImpl. > invoke(DelegatingMethodAccessorImpl.java:25) > >> at java.lang.reflect.Method.invoke(Method.java:585) > >> at > >> org.junit.internal.runners.BeforeAndAfterRunner. > invokeMethod(BeforeAndAfterRunner.java:74) > >> at > >> org.junit.internal.runners.BeforeAndAfterRunner. > runBefores(BeforeAndAfterRunner.java:50) > >> at > >> org.junit.internal.runners.BeforeAndAfterRunner. > runProtected(BeforeAndAfterRunner.java:33) > >> at > >> org.junit.internal.runners.TestMethodRunner. > runMethod(TestMethodRunner.java:75) > >> at > >> org.junit.internal.runners.TestMethodRunner.run(TestMethodRunner.java:45) > >> at > >> org.junit.internal.runners.TestClassMethodsRunner. > invokeTestMethod(TestClassMethodsRunner.java:75) > >> at > >> org.junit.internal.runners.TestClassMethodsRunner. > run(TestClassMethodsRunner.java:36) > >> at > >> org.junit.internal.runners.TestClassRunner$1. > runUnprotected(TestClassRunner.java:42) > >> at > >> org.junit.internal.runners.BeforeAndAfterRunner. > runProtected(BeforeAndAfterRunner.java:34) > >> at org.junit.internal.runners.TestClassRunner.run(TestClassRunner.java:52) > >> at > >> org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference. > run(JUnit4TestReference.java:38) > >> at > >> org.eclipse.jdt.internal.junit.runner.TestExecution. > run(TestExecution.java:38) > >> at > >> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner. > runTests(RemoteTestRunner.java:460) > >> at > >> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner. > runTests(RemoteTestRunner.java:673) > >> at > >> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner. > run(RemoteTestRunner.java:386) > >> at > >> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner. > main(RemoteTestRunner.java:196) > >> Caused by: java.lang.NullPointerException > >> at > >> org.apache.tuscany.sca.assembly.xml.BaseArtifactProcessor. > declareNamespace(BaseArtifactProcessor.java:681) > >> at > >> org.apache.tuscany.sca.assembly.xml.BaseArtifactProcessor. > loadElement(BaseArtifactProcessor.java:732) > >> at > >> org.apache.tuscany.sca.assembly.xml.BaseArtifactProcessor. > readPropertyValue(BaseArtifactProcessor.java:633) > >> at > >> org.apache.tuscany.sca.assembly.xml.BaseArtifactProcessor. > readAbstractProperty(BaseArtifactProcessor.java:332) > >> at > >> org.apache.tuscany.sca.assembly.xml.BaseArtifactProcessor. > readProperty(BaseArtifactProcessor.java:348) > >> at > >> org.apache.tuscany.sca.assembly.xml.CompositeProcessor. > read(CompositeProcessor.java:231) > >> at > >> org.apache.tuscany.sca.assembly.xml.CompositeProcessor. > read(CompositeProcessor.java:68) > >> at > >> org.apache.tuscany.sca.contribution.processor. > ExtensibleStAXArtifactProcessor.read(ExtensibleStAXArtifactProcessor.java:73) > >> at > >> org.apache.tuscany.sca.assembly.xml.CompositeDocumentProcessor. > read(CompositeDocumentProcessor.java:63) > >> at > >> org.apache.tuscany.sca.assembly.xml.CompositeDocumentProcessor. > read(CompositeDocumentProcessor.java:43) > >> at > >> org.apache.tuscany.sca.contribution.processor. > ExtensibleURLArtifactProcessor.read(ExtensibleURLArtifactProcessor.java:73) > >> at > >> org.apache.tuscany.sca.contribution.service.impl. > ContributionServiceImpl.processReadPhase(ContributionServiceImpl.java:369) > >> at > >> org.apache.tuscany.sca.contribution.service.impl. > ContributionServiceImpl.addContribution(ContributionServiceImpl.java:313) > >> at > >> org.apache.tuscany.sca.contribution.service.impl. > ContributionServiceImpl.contribute(ContributionServiceImpl.java:160) > >> at > >> org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain. > <init>(DefaultSCADomain.java:117) > >> at > >> org.apache.tuscany.sca.host.embedded.SCADomain. > createNewInstance(SCADomain.java:230) > >> ... 22 more > >> > >> Do you think that both issues are bugs? Should I report a Jira for them? > >> > > > >This is a bug. The code doesn't handle the case that the target > namespace is > >null. > > > >> > >> Now about the other stuff :) > >> > >> About 2: Let me explain my impression first, why I thought I have done a > >> hack: When the SCA Domain is started, upon java interface introspection, > >> the databindings of the Interface -> Operation -> DataType-s areset. And > >> this is done only if the interface is declared to be remotable. Otherwise > >> the databinding remains null. > >> However, when the runtime components are initialized - in the XQuery > >> implementation provider I set databindings for the same Interface -> > >> Operation -> DataType-s to Saxon. > >> I don't know why, but this tricks the framework, when creating the wires > >> to include data transformer in the invocation chain. I haven't elaborated > >> why this happens, because it worked. But I think that it is better for my > >> implementation provider in some way to explicitely state that hewants to > >> set only the data binding of the target operation, not generally the > >> databinding of the Interface -> Operation -> DataType-s > > > >We had some discussions in this area before. There are a few factors: > > > >1) A model object represents the XML definition for <interface.xxx> > >elements, say XXXInterface. > >2) The interface type which is introspected from the java interface or WSDL > >portType. The same type can be referenced by multiple <interface.xxx> > >elements and therefore it can be shared by multiple XXXInterface instances. > >3) A way to indicate the databinding for an instance of > XXXInterface. If not > >specified, the databinding is default to the one in the interface type. > > > >At this moment, we don't have a clean separation of 1 & 2. We should fix it > >before the 1.0 release. > > > >> > >> About 4: Sorry i is my mistake. I ment the net.sf.saxon.Configuration > >> object. I want to preserve it the first time it is created for a given > >> invokation. For example this could happen when for first time DataObejct > >> is transformed to NodeInfo. The I want all further transformation and the > >> invokation in the XQueryInvoker to use the same configuration object. I > >> want that this configuration object is invalidated after the invocation > >> finishes. Currently I am doing not very good workaronds to prevent this: > >> see comments in SaxonDataBindingHelper and XQueryInvoker for details. > >> > >> About 7: This is an assumption I make in the > >> DataObject2NodeInfoTransformer in order to serialize the DataObject to an > >> output stream, which is then used to prepare the NodeInfo Saxon object > > > >FYI, the tuscany databinding framework can support multi-hop transformation > >by leveraging transformers in the graph.For example, if we have two > >transformers in Tuscany: > > > >Transformer 1: SDO --> XMLStreamReader > >Transformer 2: XMLStreamReader --> Saxon NodeInfo > > > >Then we can convert SDO into NodeInfo without writing a direct transformer > >from SDO to Saxon NodeInfo. > > > >I'll look into the databinding-saxon more and comment later. > > > >> > >> About 8: OK. I will retest and create a Jira if necessary. > >> > >> About scope: This was just a thought. But if we consider the scenarios > >> where this implementation will be used (data integration and mediation) I > >> do not see any use. > >> > >> Bye, Vasil > >> > >> >-------- Оригинално писмо -------- > >> >От: Jean-Sebastien Delfino <[EMAIL PROTECTED]> > >> >Относно: Re: Current XQuery implementation issues > >> >До: [email protected] > >> >Изпратено на: Вторник, 2007, Август 21 22:44:32 EEST > >> >---------------------------------- > >> > > >> >Hi Vasil, > >> > > >> >Some comments, answers, and more questions :) inline. > >> > > >> >Vasil Vasilev wrote: > >> >> Hi All, > >> >> > >> >> You can take a look at > >> >> http://issues.apache.org/jira/browse/TUSCANY-1536 > >> >> for a list of current issues with the XQuery implementation. > >> >> > >> >> For issues 1 and 6 a wrote an e-mail to the Saxon mailing > list and I am > >> >> waiting for an answer. > >> >> > >> >> For the other issues: > >> >> 2. I need the data type of the input and output of the data that go > >> >> into and out of the XQueryInvoker be of the Saxon data type. > That's why > >> >> I need to set the data binding in some way from the side of the > >> >> XQueryInvoker. What I am not sure is if this is the right way, or is > >> >> this more a hack to do it? > >> >> > >> > > >> >What you're describing sounds right to me. The general idea is that an > >> >implementation should be able to tag the interface it's providing or > >> >requiring with a particular databinding (because the implementation > >> >logic wants that particular databinding, or because the technology > >> >you're using in your implementation extension works with that > >> >databinding, Saxon in your case). > >> > > >> >I'd be interested in your feedback and whether you think it's easy > >> >enough to do, or if it feels more like a hack :) > >> > > >> >You also mentioned in the JIRA that you had to make the interface > >> >remotable. There may be an issue with the Tuscany databinding framework > >> >here, I'd imagine that it you had a string of XQuery components (all > >> >using the same Saxon binding), you'd probably not want to have to mark > >> >their interfaces remotable. > >> > > >> >Raymond, what do you think? Isn't that an issue? why couldn't this work > >> >with a local interface as well? > >> > > >> >> 3. I didn't have the time to do it, but generally it is possible to be > >> >> done. > >> >> > >> > > >> >Yes I'd think so. It looks like a good thing to do as I guess most > >> >XQuery component developers will work with XSDs and will probably > >> >interact with Web Services as well. > >> > > >> >Some may even say that they only care about XML and don't want to have > >> >to deal with any Java code or Java interface :) > >> > > >> >> 4. I would like to know if a can use some kind of context, which is > >> >> associated with given request and if I can use this context > to put some > >> >> data there. I do not want this context to be transferred in > web service > >> >> invocation for example, but only in the chain of transformers to the > >> >> target invoker. > >> >> > >> > > >> >We may be able to extend the Tuscany Message or EndpointReference to > >> >carry extra context data, but could you give me a little more background > >> >on what kind of data you'd like to pass or keep around, and how it's > >> >going to be used? > >> > > >> >In the JIRA you mentioned "which configuration is associated with an > >> >invocation"... The message carrying an invocation should have pointers > >> >to assembly model representing the from (reference) and target > >> >(service), from which I think you could navigate to the binding model > >> >and its configuration. Is that the kind of configuration you're looking > >> >for? or some other configuration? > >> > > >> >> 5. This limitation is again due to the fact I didn't have time to > >> >> implement it. > >> >> > >> > > >> >Ok, time is always too short :) > >> > > >> >> 7, and 8 - are just questions if somebody knows is this the right way > >> >> to do it. > >> >> > >> > > >> >For 7, are you talking about Web Services? or is it an assumption you > >> >made in the XQuery component? > >> > > >> >(8) looks like bug, we should create a JIRA for it. > >> > > >> >> Another thing that we should think about is whether it is useful to > >> >> provide a scope for the XQuery implementation. Currently it is not > >> >> scoped. > >> >> > >> >> > >> > > >> >Ah interesting, I'm not an XQuery expert :) so do you have an example > >> >showing the kind of state that an XQuery component could support? > >> > > >> >Are you thinking about keeping variables around across multiple > >> >invocations of the same component? > >> > > >> >Thanks... > >> > > >> >> Bye, Vasil > >> >> > >> >> ----------------------------------------------------------------- > >> >> Познай победителя във Формула 1 и спечели награда! > >> >> http://www.clubf1.net/ > >> >> > >> >> --------------------------------------------------------------------- > >> >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> >> For additional commands, e-mail: [EMAIL PROTECTED] > >> >> > >> >> > >> >> > >> > > >> > > >> >-- > >> >Jean-Sebastien > >> > > >> > > >> >--------------------------------------------------------------------- > >> >To unsubscribe, e-mail: [EMAIL PROTECTED] > >> >For additional commands, e-mail: [EMAIL PROTECTED] > >> > > >> > > >> > >> ----------------------------------------------------------------- > >> ЕЛА и направи свой сайт, намери нови приятели! > >> http://www.zoom.bg/ > >> > >> --------------------------------------------------------------------- > >> 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] > > > > > > ----------------------------------------------------------------- > ЕЛА и направи свой сайт, намери нови приятели! > WWW.ZOOM.BG > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] >
