Thanks for the response, can you clarify that <any> will allow any element even if that element is currently unknown to the schema? If it behavews like dtd ANY, which allows any of the defined elements to appear it does not help. I will have a look at the Schema spec shortly too.
Thanks, --jason On Monday 27 May 2002 05:25 am, Arnaud Blandin wrote: > 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 ----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to [EMAIL PROTECTED] with a subject of: unsubscribe castor-dev
