Hi Jason, It seems that you need the wildcard mechanism of XML Schema. You should indeed use an <any> element in your schema to represent your <myconfig> stuff. Please take a look at the XML Schema recommendation [1]. As for the support of <any> in Castor there is no written documentation yet but you can always take a look at what Castor is generating and the class org.exolab.castor.types.AnyNode. If you needed more inputs, feel free to ask the list.
Arnaud [1] http://www.w3.org/TR/xmlschema-1/#Wildcards > -----Original Message----- > From: Jason Dillon (by way of Jason Dillon <[EMAIL PROTECTED]>) > [mailto:[EMAIL PROTECTED]] > Sent: Sunday, May 26, 2002 1:57 AM > To: [EMAIL PROTECTED] > Subject: [castor-dev] Non-schema elements, XML namespace and JBoss3 > configuration (oh my) > > Hello, > > I am investigating replacing the XML parsing of config and metadata files in > JBoss3 with Castor. I have used Castor XML and JDO before, but I am still a > beginner when it comes to doing anything non-trival with it. > > I am hoping that someone might have some insight on the issues below, so I > can avoid wasting too much time in trial and error (and possible failure if > what I am trying to perform is not possible). > > The problem is that in JBoss3 we have many different config and metadata > files which many different components need to have access to. Currently > there is custom XML parsing, which uses inconsistent logic to process > elements (such as handling CDATA and non-CDATA text elements, triming for > non-CDATA, property substitution and so on). > > The solution is to use a framework to generate an object model from the XML > data, which will allow common processing of elements and will also simplify > higherlevel components, allowing them the concentrate on their task and not > XML. > > Sounds reasonable, so here comes the snag, which I think that XML namespaces > might solve, but I am not sure how this relates to Castor (or really any > other object binding framework). > > Consider the following service.xml snippet: > > <server> > <mbean code="my.package.MyService" name="my:type=MyService"> > <attribute name="SomeAttribute">Some Textual Data</attribute> > <attribute name="SomeConfig"> > <myconfig> > <myelement/> > </myconfig> > </attribute> > </mbean> > </server> > > <server>, <mbean> and <attribute> are all part of the service schema, or > really they could be part of a schema or dtd. <myconfig> and <myelement> are > specific to MyService. This is a mechanism that allows the service.xml file > to contain a snippet of service specific configuration, rather than using a > textual data attibute with a url to a file. > > Currently we parse "SomeAttribute" as String and "SomeConfig" will be passed > to the service as an Element, letting it make use of any rich xml config it > needs. > > Given the above, it is my understanding that I can not make a dtd or schema > that could ever be used to validate this document or genrate an object model > from. If I am wrong please drop some knowledge ;) > > Based on some reason of XML namespaces, I think that it is possible to fix > this at an XML level by using something like the following: > > <server xmlns="http://jboss.org/service"/> > <mbean code="my.package.MyService" name="my:type=MyService"> > <attribute name="SomeAttribute">Some Textual Data</attribute> > <attribute name="SomeConfig"> > <my:myconfig xmlns:my="http://my.package"/>> > <my:myelement/> > </my:myconfig> > </attribute> > </mbean> > </server> > > I think this should allow an XML parser to validate this document, or at > least the service schema bits, but honestly I am not sure. > > But what will Castor do? Is it possible even use Castor to generate a model > from this? Ideally I would like to tell Castor to simply map any elements > found under a <attribute> tag, as an Element and then move on. > > One possible solution, which I don't like too much at all, is to use a CDATA > element to escape the <myconfig> elements. Then I treat it like textual > data, and let the service handle parsing it. > > Does anyone have any insight on how I might solve this problem (and the > related snag) with Castor? > > Thanks, > > --jason > > ----------------------------------------------------------- > If you wish to unsubscribe from this mailing, send mail to > [EMAIL PROTECTED] with a subject of: > unsubscribe castor-dev ----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to [EMAIL PROTECTED] with a subject of: unsubscribe castor-dev
