This is not really a request for time or resources - you work on Castor at whatever pace you feel comfortable - this is a technical comment only.
If you consider my proposal as a step 2 to be taken after step 1, then I'm not sure I understand what you have in mind for step 1 is. I note that Castor as is unmarshals to AnyNodes, and that I can easily marshal an AnyNode into a StringWriter, and unmarshal manually to the target name space's binding (provided I know which one it is.) That part works. Can you clarify what you mean by "unmarshalling from AnyNode?" - Godmar On Tue, Apr 22, 2008 at 2:03 PM, Werner Guttmann <[EMAIL PROTECTED]> wrote: > Godmar, > > I hear what you are trying to say, but I'd introduce such features step > by step. In other words, yes, I'd like to head for a more advanced > solution as well, but let's introduce basic features as well .... > > It's basically trying to manage the time I have at hands as well. I'd > like to spend 20+ hours a week on Castor, but unless somebody makes some > cash available to me in one way or the other, I have to earn a living as > well. > > Bye > Werner > > > > Godmar Back wrote: > > Are you thinking of the issue discussed in > > http://www.mail-archive.com/[email protected]/msg05901.html ? > > > > If so, let me point out that to handle the case in which XML described > > by schema B is embedded in an <xs:any> location occurring in schema A, > > I would much rather not "see" an AnyNode at all. That is, I don't want > > to have to invoke marshal/unmarshal if Castor can infer what > > marshaling and unmarshaling needs to be done ----- it would be even > > better if it could avoid any unnecessary unmarshaling in the first > > place. > > > > I believe that the correct unmarshaling strategy can be inferred from > > the namespace used for the element. For instance, if an element that > > occurs in a ##any position is, in a concrete XML document: > > > > <larger document> ..... > > <ad:aboutData > > xmlns:ad="info:rfa/rfaRegistry/xmlSchemas/Institutions/aboutData" > > .... > > .... > > > > then castor should use the "info:rfa/...." name space to unmarshal > > this part of the document. > > > > To accomplish the correct unmarshalig, Castor would at runtime need > > access to a set of mappings between XML name spaces and Java classes > > --- I do not know if Castor already has this ability, but I wouldn't > > be surprised if it did. > > > > Implementation wise, I'd expect that whenever I run > > "org.exolab.castor.builder.SourceGenerator" on a schema, an entry > > should be added that associates the targetNamespace of the schema with > > the Java classes created. In the example above, suppose I run > > SourceGenerator on a schema "aboutData.xsd" which contains: > > > > <xs:schema > targetNamespace="info:rfa/rfaRegistry/xmlSchemas/Institutions/aboutData" > > ..... > > > > > then I'd expect that instance of the Java classes generated by this > > schema will show up when I unmarshal a document that contains the > > "ad:aboutData" mentioned above, without me having to do anything. > > > > - Godmar > > > > On Tue, Apr 22, 2008 at 1:15 PM, Werner Guttmann <[EMAIL PROTECTED]> wrote: > >> Hi, > >> > >> as there have been some requests recently to support unmarshalling from > >> an AnyNode instance, I have started working on this. Can I please ask > >> anybody to supply me with one or more test cases that allowed me to > >> think and code against a contract. > >> > >> And if there is no Jira issue, feel free to add a new one (marked as > >> feature request) or point me to an existing one. > >> > >> Regards > >> Werner > >> > >> PS Yes, I could equally build this myself, but I'd rather spend the time > >> trying to help you as much as possible, and reuse your time an knowledge > >> as much asp possible. > >> > >> --------------------------------------------------------------------- > >> To unsubscribe from this list, please visit: > >> > >> http://xircles.codehaus.org/manage_email > >> > >> > >> > > > > --------------------------------------------------------------------- > > To unsubscribe from this list, please visit: > > > > http://xircles.codehaus.org/manage_email > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
