Hi Brian, In the castor mapping XML Schema, name is of type 'ID' for class because this classname can be used elsewhere in the mapping to refer to the class. Indeed 'depends' and 'extends' are directly used to refer to a class whose mapping is defined in the mapping file.
Concerning NMTOKEN, I am not sure of which 'type' you are talking about?(what is the parent element?) but I can assure you that ID is not a super set of NMOTKEN, there is no relation between the two. Arnaud "This message is intended only for the use of the Addressee and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not the intended recipient, dissemination of this communication is prohibited. If you have received this communication in error, please erase all copies of the message and its attachments and notify us immediately." > -----Original Message----- > From: bikehead [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, September 17, 2002 5:46 PM > To: [EMAIL PROTECTED] > Subject: Re: [castor-dev] Using OQL with inner classes... > > Well I have a patch to allow inner class names in OQL names, but I > have > another issue that is more troublesome. So right now one can use an > inner class name in a mapping and in OQL, but one cannot use it in a > relationship. The reason is that the XSD for the mapping file > defines > 'type' as NMTOKEN ', but the class 'name' is ID. These are actually > incompatable since NMTOKEN doesn't allow '$'. While I can change the > XSD to ID, I'm not sure of the full ramifications. I *think* it is > a > backward compatable change since it appears that ID containse > NMTOKEN > sets. Any thoughts? > > -Brian > > > Bruce Snyder wrote: > > >This one time, at band camp, bikehead said: > > > >b>I can't use db.load() because I want to iterate over every > persistent > >b>instance of a class and there doesn't seem to be any other way to > do > >b>this. db.load requires an identifier which I don't have. > > > >I see. > > > >b>I'm working on a fix for this in org.exolab.castor.jdo.oql.Parser > and > >b>ParserTreeWalker. It appears to be a simple case of getting the > parser > >b>and expression builder to recognize '$' as a valid delimiter in a > >b>iterator specification. > > > >This is exactly why I wanted the line numbers in the stack trace. I > know > >it's in the ParserTreeWalker somewhere. Eventually I'd like to > rework > >the OQL implementation to make use of ANTLR. It's modeled after > ANTLR, > >but when using ANTLR, a lot of the code can be generated during the > >build process. Makes for very easy changes to the implementation ;- > ) > > > >Let me know if you create a patch for this issue. > > > >BTW, thanks for you hard work. > > > >Bruce > > > > > > -- > __o > _-\<,_ Brian > (_)/ (_) [EMAIL PROTECTED] x503 > > > ----------------------------------------------------------- > 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
